CISA: gestolen wachtwoorden en phishing zwakke plek overheidsinstanties
Gestolen en standaard wachtwoorden en phishing zijn de zwakke plekken van overheidsinstanties. Dat oordeelt het Cybersecurity and Infrastructure Security Agency (CISA) van het Amerikaanse ministerie van Homeland Security op basis van eigen onderzoek (pdf). Het cyberagentschap voerde vorig jaar samen met de Amerikaanse kustwacht (USCG) 143 beveiligingstests uit bij federale overheidsinstanties.
'Valid accounts', een overkoepelende term, waar onder andere gestolen, gekraakte en standaard wachtwoorden onder vallen, was verantwoordelijk voor 41 procent van de succesvolle pogingen om toegang tot een organisatie te krijgen. Zo was het kraken van wachtwoordhashes in 89 procent van de tests die de USCG uitvoerde succesvol om toegang tot Domain Administrator accounts te krijgen. Valid accounts zijn bijvoorbeeld ook accounts van voormalige medewerkers die nog steeds actief zijn. Zo ontdekte de kustwacht die bij het uitvoeren van de beveiligingstests betrokken was dat bijna 95 procent van de onderzochte overheidsinstanties gebruikmaakte van standaard wachtwoorden.
Op de tweede plek met meer dan 26 procent volgen phishing of spearphishing, aldus het CISA. Naast de bevindingen van de beveiligingstests doet het CISA ook verschillende aanbevelingen, zoals het implementeren van sterk wachtwoordbeleid en phishingbestendige multifactorauthenticatie (MFA). Ook wordt aangeraden om logbestanden te monitoren om zo verdachte inlogpogingen te detecteren. Vervolgens moet er snel op verdachte activiteiten worden gereageerd.
Bijvoorbeeld de EDIW (of EUDIW, European Digital Identity Wallet) is geheel niet phishingresistent [2].
Bij websites die je voor het eerst bezoekt heb je daar sowieso niets aan MFA (welke soort dan ook). Denk bijv. aan gegooglde webshops, sites waarvan je de authenticiteit van geboden informatie (waaronder -potentieel fake- nieuws en/of links naar andere sites en/of downloads) vertrouwt, of websites waarop je vertrouwelijke gegevens deelt en/of een account aanmaakt.
[1] Potentiële passkey en FIDO2 hardware key phishing (Engelstalig): https://infosec.exchange/@ErikvanStraten/113124204291514950
[2] EDIW, phishing en de EV-moord (Nederlandstalig): https://infosec.exchange/@ErikvanStraten/113031344934186250
Fix: https://infosec.exchange/@ErikvanStraten/113079966331873386, daaruit:
En uit https://infosec.exchange/@ErikvanStraten/113132670693985681:
Simplified one can distinguish between three layers:
2: [you]·········virtual channel····[owner]
1: [browser]··virtual channel····[httpd]]
0: [OS/hw]———network———[OS/hw]
("owner" means the person(s) responsible for a website).
What happens in layer 0 is irrelevant when you open websites in your browser, because httpd (the web server software) either has access to the private key associated with the public key in the certificate (that the server sent to the browser), or it has not.
That makes layer 1 (which uses domain names to identify websites) fully independent of the network layer (including DNS, routing, IP-adresses, MAC-adresses etc).
In fact, TLS could work fine without using IP addresses, DNS, routing protocols and any network hardware - for example by having the OS print network packets in BASE64 on postcards and send them to the server via snail mail.
The problem with layer 1 is that domain names are potentially meaningless (as you notably argued yourself in one of your other toots: the TLD ".pl" does *not* necessarily mean that the server or owner has anything to do with Poland - which is *exactly* what I was trying to point out).
To get connected to the correct server (and not see a certificate error) it is imperative that DNS is not messed up by letting multiple entities register the same domain name (and have it point to different IP-addresses), or by attackers returning spoofed DNS replies. Certificates do not prevent such attacks, but they *do* reliably help browsers detect spoofing and/or AitM's in order to warn the user in layer 2.
However, while domain names are fine for layer 1, people (layer 2) simply need more information *BECAUSE* domain names are potentially misleading.
[...]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
