Onderzoek: bijna iedereen kan slachtoffer van phishing worden
Bijna iedereen kan het slachtoffer van phishing worden en een gevaarlijke link of bijlage openen, ook al is men securitybewust, zo claimt een Duitse onderzoekster. Zinaida Benenson leidt een onderzoeksgroep die de menselijke factoren analyseert die bij security en privacy een rol spelen. Ze onderzocht waarom mensen een kwaadaardige link of bijlage wel of niet openen. Deze week geeft ze tijdens Black Hat een presentatie over de onderzoeksresultaten.
"Door het ontwerp en de timing van het bericht goed te plannen is het mogelijk om bijna elk persoon op een link te laten klikken, aangezien ieder mens nieuwsgierig is, in een onderwerp is geïnteresseerd of zich in een bepaalde levenssituatie bevindt waar de inhoud en context van het bericht op aansluiten", aldus Beneson tegenover ZDNet. Volgens de onderzoekster maken mensen vooral fouten vanwege de context van een bericht en nieuwsgierigheid.
Onderzoek
Voor het onderzoek besloten de onderzoekers meer dan 1600 universiteitsstudenten een e-mail of Facebookbericht van een niet-bestaand persoon te sturen. Het bericht beweerde dat de meegestuurde link foto's van een recent feestje bevatte. Als de ontvanger bij zijn voornaam werd genoemd werd de link door 56% van de e-mail- en 38% van de Facebookgebruikers geopend. Was de voornaam niet vermeld, dan opende 20% van de e-mailgebruikers het bericht tegenover 42,5% van de Facebookgebruikers. Toch wist 78% dat het openen van een link gevaarlijk kan zijn.
De voornaamste reden voor het openen van een link was nieuwsgierigheid over de inhoud van de afbeelding, gevolgd door de context die op de levenssituatie van de ontvanger aansloot. Zo waren ontvangers echt recentelijk op een feestje met vreemden geweest. Daarnaast dacht 16% dat ze de afzender kenden. De voornaamste reden om de link niet te openen was dat de afzender onbekend was, gevolgd door de context die niet aansloot bij de situatie van de ontvanger.
"We laten zien dat nieuwsgierigheid, of interesse in het onderwerp en context van de aanval de belangrijkste rol spelen bij de onveilige beslissing die gebruikers maken, wat het lastig maakt om vaardige aanvallers te dwarsbomen", laat Beneson weten. Ze stelt dat het lastig is om tegen dit soort aanvallen te beschermen. "Natuurlijke en creatieve menselijke eigenschappen, zoals nieuwsgierigheid, zullen altijd kunnen worden uitgebuit, aangezien mensen (hopelijk) niet tegen dit soort aanvallen kunnen worden gepatcht." Door haar onderzoek hoopt ze echter meer inzicht in de beweegredenen van mensen te geven, zodat verdedigers betere beveiligingsmethodes kunnen ontwikkelen.
Stel je nu echt voor dat een ieder alleen met geverifieerde persoonsgegevens (afzender) herleidbaar en traceerbeer een bericht mag versturen. Ik stel de mogelijkheid tot geheimhouding / privacy zeer op prijs. Niet alles hoeft open te zijn.
Het is te zot voor woorden dat er nog mensen zijn die niet weten dat er al decennia 2 bekende manieren zijn om klassieke e-mail te ondertekenen, waarmee dit probleem al lang uit de wereld geholpen had kunnen zijn als IT afdelingen bij grote bedrijven zouden snappen hoe ze het moeten implementeren.
We hebben een methode, maar die wordt weinig toegepast. GPG is de beste methode van persoon naar persoon berichtenverkeer. Helaas zijn de implementaties niet zo best. Ook laat het headerdata onversleuteld, waaronder het onderwerp.
Verder kunnen berichten worden gesigneerd door organisaties. Dat gebeurt veel te weinig en het laat wel wat zien van de incompetentie van die organisaties.
Het protocol zelf kan al werken met diverse vormen van versleuteling tijdens transport (client naar server of server naar server).
N.B. negeer de residente trol.
Met de slakkenpost heb je ook geen garantie w.b. de afzender.
Ik vind het te zot voor woorden dat je anno 2016 nog via een link besmet kan worden. In mijn ogen ligt de oplossing daarvoor bij de OS bouwers.
Het enige dat ik wil is dat als ik een mail van user@domain.tld ontvang, ik ook zeker wil zijn dat de mail afkomstig is van de gebruiker 'user' op het domain 'domain.tld'.
Waarbij het in veel gevallen wenselijk is om te weten wie de persoon of organisatie is achter die identiteit is, maar strikt noodzakelijk is dat niet (bijv. OpenXOR@example.com is prima, mits daar steeds één en dezelfde persoon achter zit). Alleen dan kan er een vertrouwensrelatie worden opgebouwd (die overigens niet wederzijds hoeft te zijn).
En vermoedelijk wil iedereen dat (behalve phishers).
Ik ken maar 1 manier om dat goed te organiseren (ik verneem graag alternatieven):
1) De identiteit achter de afzender moet over een gegarandeerd wereldwijd uniek en voldoende sterk asymmetrisch sleutelpaar beschikken waarbij, met de huidige technologie, de private key niet uit de public key en/of uit uitgewisselde informatie kan worden herleid;
2) Ik moet over de public key beschikken en zeker weten dat die public key van de identiteit van de afzender is;
3) Ik moet zeker weten dat niemand anders dan de afzender over de private key beschikt. Dit betekent ook dat ik onmiddellijk moet worden gewaarschuwd als anderen (mogelijk) toegang hebben gehad tot de private key van de identiteit achter de afzender, en vanaf wanneer;
4) Het hele e-mail bericht, inclusief verzenddatum en -tijd [begin aanvulling 12:12, met dank aan Anoniem 00:44] en alle voor de ontvanger relevante headers waaronder Subject (onderwerp), To, Cc en evt. Reply-To [einde aanvulling 12:12], moet digitaal zijn gesigneerd met de private key gebruikmakend van een voldoende veilige cryptografische hash;
5) Ik moet zeker weten dat de afzender de digitale handtekening heeft gezet over de daadwerkelijk door haar of hem geschreven tekst plus de actuele datum en tijd [begin aanvulling 12:18] en voor de ontvanger relevante headers (zie punt 4) [einde aanvulling 12:18];
6) [tussengevoegd om 08:51] Ik moet zeker weten dat de software die ik gebruik mij niet voor de gek houdt;
7) Alle MUA's (mail user agents = mail clients = e-mail programma's) moeten hier ondersteuning voor bieden.
Dat is alles...
Link: http://www.teusink.eu/2016/04/need-security-awareness-youre-doomed.html
Mail kan overigens wel een stuk beter beveiligd worden met bestaande hulpmiddelen. Vaak doen bedrijven dat alleen niet. Denk hierbij aan TLS, DMARC, Reverse DNS, Sender Policy Framework (SPF), DNS-based blacklists, en Spam URI Real-time Block Lists (SURBL).
Je klikt immers constant op links waarvan je niet zeker weet of ze betrouwbaar zijn tijdens het surfen. Of jullie niet?
En ook al zou je de bron van een email kunnen verifiëren kan deze nog steeds verstuurd zijn vanuit een gecompromitteerd account of vanaf een gehackte computer van een vriend,klant of collega
Het gaat er om dat je je account gegevens niet in invult op een website van een aanvaller en dat je geen bijlages of downloads start die schadelijke code kunnen bevatten en je systemen up-to-date houden.
Wanneer ze met zero-days aan komen die ze kernel/system/root rechten geeft of exploits waarmee ze invloed op je processor of ander hardware met DMA kunnen uitoefenen gaat welke beveiliging dan ook falen.
Het probleem hier is nog steeds "Key Signing", dat moet je zelf doen https://www.phildev.net/pgp/gpgsigning.html
Leg dat maar eens uit aan je oma
Deze posting is gelocked. Reageren is niet meer mogelijk.
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.
