Computerbeveiliging - Hoe je bad guys buiten de deur houdt

Vreemde bunq e-mail

19-07-2024, 19:23 door Erik van Straten, 14 reacties
Eigenlijk werkte ik al een paar dagen aan een ander artikel over de toenemende onbetrouwbaarheid van internet. Toen ik echter vanochtend mijn e-mail checkte en de mail van bunq zag, vond ik dat het volgende mij eerst van mijn hart moet.

### Achtergrond ###

Uit https://opgelicht.avrotros.nl/alerts/artikel/wees-gewaarschuwd-voor-bunq-sms-over-valideren-rekening-door-veiligheidsupdate/ van 14 maart:
In beide links ‘https://verificatie·056825-nl·de’ en ‘bevestigvalidatie·com’ komt nergens de naam ‘bunq’ voor. Dit is een kenmerk dat kan wijzen op phishing.
AARRGGHH!!

Nb. "links" worden ook URL's, weblinks of webadressen genoemd.

Enkele van zeer vele voorbeelden van phishing-sites *met* bunq in de domeinnaam (op slechts één server in Rusland, bron: https://www.virustotal.com/gui/ip-address/91.215.85.79/relations - Nb. ik heb hierboven en hieronder steeds '.' (punt) door '·' vervangen om het onbedoeld openen van phishingpagina's te voorkómen):
Datum #Det. Domeinnaam
240616 0/93 www·verificatie-online-bunq-nl·com
240615 0/93 www·bevestigen-bunq-nl·com
240603 0/93 bunq-identificeren-nl·com
240530 8/93 verificatie-online-bunq-nl·com
240522 0/93 web-bunq-informatiecontrole·com
240522 0/93 web-bunq-klantenportaal·com
240520 0/93 mijn-bunq-omgeving·com
240518 0/93 bunq-gegevens-bijwerken-nl·com
240516 0/92 bij-werken-nu-nl-bunq·com
240515 0/92 nl-bunq-bijwerken·com
240510 5/92 werk-nu-bij-bunq-nl·com
240508 0/92 bunq-nl-bijwerken·com
240506 6/91 bevestigen-bunq-nl·com
240506 0/91 regel-mijn-bunq-nl·com
240505 0/91 identificeren-nl-bunq-nl·com
240504 4/91 nl-online-bunq-nl·com
240419 3/90 werk-bij-mijn-bunq-nl·com

Eveneens uit bovengenoemde "Opgelicht" pagina:
Om zo veilig mogelijk te blijven adviseert de bank om geen links te volgen als je een bericht ontvangt dat van bunq afkomstig lijkt te zijn.

### Ontvangen bunq e-mail ###

Gisteren ontving ik de volgende e-mail:
From: bunq <no-reply@hello.bunq.com>
Date: 18 July 2024 at 21:14:21 CEST
To: Erik(rest door Erik verwijderd)@xs4all.nl
Subject: Verdien tot 3,36% rente!

[bunq-logo] 18-07-2024
Sparen met bunq

Hey E,


Je kan ervan uitgaan dat we je altijd de hoogst mogelijke rente op je spaargeld bieden. Hoewel de Europese Centrale Bank de rente onlangs heeft verlaagd, introduceren wij nu een bonusrente van 3,36% om extra sparen te belonen.

Zo werkt de bonusrente:
• Je nieuwe basisrente is 2,16%

• Elk half jaar krijg je bonusrente over spaartegoeden die boven je hoogste spaarsaldo van het voorgaande half jaar uitstijgen. Deze bonusrente is 3,36%

• Stort je voor 31 december geld op je spaarrekening en is je saldo hiermee hoger dan €0.00, dan verdien je maar liefst 3,36% rente op je extra spaargeld!

• Ga voor een voorbeeld van hoe je wekelijkse rente nu wordt berekend naar Together [1]

Deze wijzigingen gaan in op 19 juli, 2024. Voeg vandaag alvast wat geld toe aan je spaarrekening om vanaf je volgende wekelijkse Payday al te profiteren van 3,36% rente (op tegoeden tot €100.000).

[ Voeg geld toe ] [2]

Ga voor meer info over onze nieuwe rentetarieven naar Together [3].

Cheers,

bunq
bank of The Free


[Phishing-icon]
Houd je geld veilig
Voor jouw veiligheid nemen bunq medewerkers NOOIT telefonisch contact met je op.
We vragen NOOIT om je pincode of gebruikersgegevens.
Als iemand je belt en beweert een medewerker van bunq te zijn, hang dan op en meld dit hier [4].

[header-welcome]
[facebook] [twitter] [instagram]

© 2024 bunq, all rights reserved.
bunq BV - Naritaweg 131 - 133 - 1043 BS - Amsterdam
KVK number 54992060
Afmelden [5] | Contact [6]

Alle links beginnen met: https://clicks.bunq.com/f/a/
- in alle gevallen gevolgd door telkens vier onleesbare reeksen van cijfers, kleine letters, hoofdletters, '-', '_' en '~':

[1] <*a>~~/<*1>~/<*2>-<*g>~~
[2] <*b>~~/<*1>~/<*2>-<*h>~~
[3] <*c>~~/<*1>~/<*2>-<*i>~~
[4] <*d>~~/<*1>~/<*2>-<*j>~~
[5] <*e>~~/<*1>~/<*2>-<*k>~~
[6] <*f>~~/<*1>~/<*2>-<*l>~~

Waarbij geldt (gebruik makend van de regex notatie):

<*1>: 7x [a-zA-Z0-9\_]
<*2>: 5x [a-zA-Z0-9\_]
<*a> t/m <*f>: 21x [a-zA-Z0-9\_\-]
<*g> t/m <*l>: 152x [a-zA-Z0-9\_]

### Analyse ###

1) Volgens opgelicht.avrotros.nl moet je er op letten of een domeinnaam het woord "bunq" bevat om te weten of het om een legitieme website van bunq bank gaat. Zoals ik bovenaan laat zien is dat extreem misleidende informatie.

2) Eveneens volgens opgelicht.avrotros.nl zou bunq in maart hebben geadviseerd om "om geen links te volgen als je een bericht ontvangt dat van bunq afkomstig lijkt te zijn.

Hoezo ben je dan, als bunq, niet compleet hersenloos bezig als je zelf mails verzendt met daarin links waar de ontvanger op zou moeten klikken? Daar suggereert bunq dan toch mee dat het eerdere advies een grapje was of zo, in elk geval dat dit niet serieus genomen hoeft te worden?

3) Bunq stuurt mij e-mails waarin de aanhef luidt:

Hey E,

Een cybercrimineel die mijn e-mail adres kent (noodzakelijk om mij te kunnen mailen) kan doodeenvoudig die aanhef namaken - zelfs zonder mijn volledige naam te kennen. Vanzelfsprekend biedt het opnemen van mijn volledige naam achter "Hey " totaal geen garantie dat het niet om een phishing mail zou gaan, want als ik zelf e-mails verstuur luidt de afzender meestal iets als:

"Erik van Straten" <E(rest door Erik verwijderd)@dom.tld

Bovendien belanden bij het alsmaar toenemende aantal datalekken, zelden uitsluitend e-mail adressen "op straat".

Echter, in veel (stompzinnige) online adviezen die beschrijven hoe internetters phishing-berichten kunnen herkennen, wordt een onpersoonlijke aanhef als één van de criteria genoemd. Dat is puur op het verkeerde been zetten dus, net als punt 1 hierboven. Dat neemt echter niet weg dat die waarschuwing vaak genoemd wordt, en bunq juist door hier van af te wijken het zichzelf en haar klanten moeilijker maakt om nep van echt te kunnen onderscheiden.

4) Bunq verstuurt dus e-mails met daarin links naar https://clicks.bunq.com - waarbij de rest van de URL nietszeggende wartaal bevat. Daarbij wordt de ontvanger uitdrukkelijk uitgenodigd om, liefst zo snel mogelijk, op één van de links te klikken (in plaats van: "open uw bunq app en check news" o.i.d.). Hoe wil bunq dat klanten die links interpreteren? Zijn URL's die grotendeels onleesbaar zijn, juist veilig of juist niet? Of maakt dat niets uit?

5) Om nep van echt te kunnen onderscheiden is het A: aanbevolen c.q. N: noodzakelijk dat (en/en):

• N: internetters beseffen dat pagina's op een nepsite volkomen identiek kunnen zijn aan die op de echte site, en zij daarom altijd als eerste de link moeten checken;

• A: internetters links analyseren vóórdat zij erop klikken ("slechts" aanbevolen omdat een link naar een URL-verkorter zelden iets zegt);

• N: (alternatief en sowieso altijd doen) internetters de link in de adresbalk analyseren na op een link te hebben geklikt (of op andere wijze een webpagina in een browser te hebben geopend);

• N: internetters weten dat uitsluitend nadat een https-verbinding tot stand is gekomen, zij er redelijk zeker van kunnen zijn dat de browser een (niet te kapen en niet af te luisteren) versleutelde verbinding heeft met een server waarvan de domeinnaam in de adresbalk van de browser wordt getoond;

• N: internetters weten hoe je herkent dat er sprake is van een https-verbinding;

• N: internetters weten wat een domeinnaam is en welk deel van een link de domeinnaam bevat;

• N: internetters weten hoe zij, in de browser die zij op dat moment gebruiken, een te lange domeinnaam voor de adresbalk (vooral op smartphones) toch in zijn geheel kunnen inspecteren (één van de trucs van phishers is het bewust gebruikmaken van zeer lange domeinnamen);

• N: internetters weten dat domeinnamen hiërarchisch zijn opgebouwd en dat de "segmenten" daarin van rechts naar links moeten worden gelezen;

• A: internetters weten dat servers met een .nl TLD (Top Level Domein) vaak, maar niet in alle gevallen, betrouwbaarder zijn dan met andere TLD's (zoals .me, .xyz maar ook .com) o.a. omdat niet iedereen op aarde al te eenvoudig een .nl-domeinnaam kan registreren;

• N: internetters precies weten wat het verschil is tussen enerzijds een '.' (punt) en anderzijds elk ander karakter (letters, cijfers en eventuele andere leestekens dan '.') in een domeinnaam;

• A: internetters weten dat voor DNS geldige domeinnamen, naast de cijfers '0'..'9', uitsluitend uit kleine letters 'a'-'z' en '-' (minnetje) mogen bestaan;

• A: internetters zich bewust zijn van optische trucjes zoals 'rn' versus 'm', 'vv' versus 'w', '0' versus 'O', 'l' versus 'I' en dergelijke;

• A: internetters zich bewust zijn van het bestaan van IDN's (International Domain Names), een visuele truc gebruikt in webbrowsers om miljoenen verschillende karakters (o.a. Chinese en Cyrillische tekens) mogelijk te maken in virtuele domeinnamen. En dat IDN's soms worden misbruikt om internetters te foppen met lijkt-op domeinnamen met daarin bijvoorbeeld een 'ï' in plaats van een 'i' (er zijn veel meer mogelijkheden, zelfs volstrekt onzichtbare);

• A: internetters zich er bewust van zijn dat een link die begint met iets als
https://nam02.safelinks.protection.outlook.com/?url=
helemaal niets hoeft te zeggen over hoe veilig zo'n link is. Helaas bestaan er allerlei vormen van dit soort redirects, waardoor het verstandig is om in elk geval de link in de adresbalk van de browser te checken nadat je op een link hebt geklikt;

• N: internetters weten dat een vertrouwd https servercertificaat noodzakelijk is voor een betrouwbare https-verbinding en dus certificaat-getelateerde waarschuwingen of foutmeldingen nooit mogen worden genegeerd;

• N: internetters weten dat een vertrouwd https servercertificaat (zonder waarschuwingen en/of foutmeldingen) uitsluitend de identiteit van de server bevestigt - en niets anders dan dat. En dus ook helemaal niets zegt over de betrouwbaarheid van de eigenaar van de server of ieder ander die daar toegang tot heeft (of, ongeautoriseerd, verkrijgt);

• N: internetters er, elke keer opnieuw, geheel zelf verantwoordelijk voor zijn om vast te stellen dat de domeinnaam (zoals getoond in de adresbalk van de browser) van de bedoelde organisatie is - voordat zij informatie in pagina's op die site vertrouwen (afgeleid van het vertrouwen dat zij in de eigenaar van die domeinnaam hebben) en/of zelf vertrouwelijke informatie in pagina's op die website invoeren;

• N: Er nauwelijks hulpmiddelen en/of organisaties zijn die hen daar betrouwbaar bij kunnen helpen (een uitzondering zijn organisaties als https://thuiswinkel.org - mits je checkt dat de domeinnaam van een organisatie daadwerkelijk bij hen als betrouwbaar geregistreerd is).

Ervan uitgaan dat de bovenstaande kennis, op z'n minst de noodzakelijke, gemeengoed is, is m.i. ongelofelijk naïef. De meeste internetters hebben echt totaal geen idee - waarmee dit, naast in het algemeen in oplichting trappen, wellicht de belangrijkste oorzaken zijn van het in online oplichting trappen

6) Erg technisch: indien de ontvanger van zo'n e-mail toevallig weet hoe doelmeinnamen zijn opgebouwd, moeten zij kennelijk denken dat de server achter de subdomeinnaam clicks.bunq.com tevens van bunq is.

Dat is waarschijnlijk niet het geval; meestal wordt het verzenden van bulk-e-mails uitbesteed aan een derde partij die ALLES van je wil weten. Het onleesbare deel van de links in de e-mail bevat uniek identificerende informatie over de ontvanger van de e-mail, alsmede (opzettelijk verhuld) de doelsite en pagina waar de browser van de link-klikker naar zal worden doogestuurd - doch niet voordat er zoveel mogelijk waardevolle en verkoopbare gegevens van die link-klikker zijn verzameld door de derde partij.

Volgens https://isc.sans.edu/tools/dnslookup.html kun je, in Nederland, via die domeinnaam clicks.bunq.com op vier verschillende servers terechtkomen, met één van de volgende IP-adressen:
18.245.60.126
18.245.60.2
18.245.60.97
18.245.60.122
Die IP-adressen zijn (volgens o.a. https://isc.sans.edu/ipinfo/18.245.60.126) door Amazon toevertrouwd aan de CDN-provider "cloudfront.net". Dat is ook te zien aan het https servercertificaat van clicks.bunq.com: hoewel daar geen andere identificerende informatie over de eigenaar van die domeinnaam in te vinden is, is dat certificaat uitgegeven door Amazon (de slager die diens eigen vlees keurt).

Dat certificaat is te zien in o.a. https://www.virustotal.com/gui/domain/clicks.bunq.com/details - een pagina waarin onder de sectie Whois Lookup nagenoeg alle relevante informatie is vervangen door "REDACTED FOR PRIVACY" (tel uit uw verlies, uw bank is zoveel mogelijk anoniem).

Als ik echter bunq.com opzoek op de eerder genoemde isc.sans.edu site, vind ik voor Nederland:
35.71.142.77
52.223.52.2
Beide ook gehost bij Amazon, maar zonder CDN en met de standaarddomeinnaam awsglobalaccelerator.com.

In https://www.ssllabs.com/ssltest/analyze.html?d=bunq.com&latest zie ik diezelfde IP-adressen terug:
35.71.142.77 a0b1d980e1f2226c6.awsglobalaccelerator.com
52.223.52.2 a0b1d980e1f2226c6.awsglobalaccelerator.com

In https://www.virustotal.com/gui/domain/bunq.com/details zie ik dat bunq.com een DV (Domain Validated) certificaat van Let's Encrypt gebruikt (in plaats van eentje van Amazon). Ook hier is de meeste "whois" informatie onleesbaar gemaakt (*u* moet natuurlijk wél zoveel mogelijk met de billen bloot).

Er bestaat ook een opmerkelijk verschil tussen:
https://internet.nl/site/clicks.bunq.com/2889400/
en:
https://internet.nl/site/bunq.com/2889454/

Die eerste heeft HSTS niet (goed) geconfigureerd, en dat vind ik not done voor een bankwebsite.

Nb. zolang alle links in mails expliciet met https:// beginnen, is geen HSTS-support geen probleem. Maar één keer een foutje (één of meer links die beginnen met http://clicks.bunq.com/ of, geheel zonder protocol-aanduiding, dus clicks.bunq.com/) kan er, in specifieke gevallen, al toe leiden dat de verbinding naar een website van een cybercrimineel wordt omgeleid. HSTS is geen panacea, maar het niet configureren is stom, laks en nergens voor nodig.

Er zijn dus meerdere aanwijzingen dat de servers achter clicks.bunq.com niet door bunq zelf worden gehuurd, maar door een andere partij (een bulk-e-mailer). Maar bewijs daarvoor is schaars dat ik dat niet snel kon achterhalen. Sowieso is er sprake van een andere derde partij (zo je wilt, vierde), namelijk Amazon. Ook die club zul je moeten vertrouwen als je "bunqiert".

### Conclusie ###

De kans om in oplichting op internet te trappen wordt steeds groter voor doorsnee internetters, doordat, in elk geval:

• Steeds meer transacties online plaatsvinden en alternatieve mogelijkheden verdwijnen;

• Het aantal cybercriminelen voortdurend lijkt te stijgen en velen professionaliseren (het zijn zelden nog hoodie-dragende puistenkoppen die naar vallende groene cijfers en letters op zwarte schermen turen, doch geöliede organisaties);

• Voorzieningen (tools en online "cloud"-diensten) voor cybercriminelen als paddenstoelen uit de grond schieten;

• De pakkans voor veel cybercriminelen verwaarloosbaar laag is;

• Het voor internetters steeds moeilijker wordt om nep van van echt te kunnen onderscheiden;

• Big tech, maar ook kleinere hosters en CDN-providers, meeverdienen aan cybercrime en dáárom de groei in de toegestane anonimiteit van servereigenaren accepteren. Én zo meewerken aan het, voor doorsnee internetters, opzettelijk lastiger maken om online nep van echt te kunnen onderscheiden;

• Organisaties, waaronder banken, de meest absurde dingen doen waarvan zijzelf, of anderen, claimen dat zij dat "natuurlijk" nooit zouden of zullen doen;

• "Behulpzame" organisaties ongelofelijk stomme adviezen geven;

• Organisaties steeds meer verantwoordelijkheden naar individuele internetters verschuiven, terwijl velen van die internetters hun schouders ophalen (als zij niet "lekker" meedoen aan victim-blaming) zolang zij zélf geen slachtoffer worden - waarbij, m.i., de meesten van hen hun kennis en de ondersteuning door o.a. virusscanners enorm overschatten.

Ongetwijfeld besef ik vanavond dat ik nog meer relevante aspecten ben vergeten te benoemen. Anyway, niet alleen de offline maatschappij verruwt, online gaat dat veel harder.

Nog even los van de datalekken die ons steeds meer om de oren vliegen, en BSOD'ende Microsoft meuk: echt een betrouwbare context (not) om eID's (zoals EDIW/EUDIW) en systemen zoals EHDS in te introduceren. Ik voorspel extreem veel slachtoffers - bij afgebouwde (of überhaupt nooit gerealiseerde) vangnetten.

Wakker worden mensen!
Reacties (14)
20-07-2024, 06:52 door Anoniem
Goed voorbeeld van veel bedrijven anno nu. Een 'no-reply' adres, bijster klantvriendelijk en een vage inhoud, je weet nog niet hoe het werkt qua bonusrente. Hoe krijgen zij dit bedacht? Niemand bij Bunq die denkt dit is niet handig?
En dan inderdaad nog de vage linkjes, die vaak een tracker zijn of via een tracker gaan.
20-07-2024, 07:01 door Anoniem
Dekt de titel de lading van deze analyse nog wel?
20-07-2024, 10:03 door Anoniem
Wordt het niet eens tijd het systeem van domeinnamen onder handen te nemen?
Het is voor malafide partijen veel gemakkelijk domeinen aan te maken die lijken op legitieme bedrijven.
20-07-2024, 11:54 door spatieman
Wederom weer een top artikel Erik !!
20-07-2024, 17:03 door Anoniem
Door spatieman: Wederom weer een top artikel Erik !!
Mee eens.
Door Erik van Straten:(..) Nog even los van de datalekken die ons steeds meer om de oren vliegen, en BSOD'ende Microsoft meuk: echt een betrouwbare context (not) om eID's (zoals EDIW/EUDIW) en systemen zoals EHDS in te introduceren.
Het is jammer dat dergelijke expert-oordelen niet op de EU-burelen ter harte worden genomen.
Zijn ze daar ziende blind of gewoon rot tot op het bot?
20-07-2024, 17:54 door Erik van Straten
Dank voor de reacties!

Door Anoniem: Dekt de titel de lading van deze analyse nog wel?
Achteraf wellicht niet. Ik haal er, al tikkend, vaak veel bij - maar het hangt m.i. wel allemaal samen.

De reden dat organisaties als opgelicht.avrotros.nl ook onverstandige adviezen geven, is -denk ik- dat er geen goede, eenvoudige, gegarandeerd werkende, adviezen bestaan. Zie ook mijn reactie hieronder.

Door Anoniem: Wordt het niet eens tijd het systeem van domeinnamen onder handen te nemen?
Het is voor malafide partijen veel gemakkelijk domeinen aan te maken die lijken op legitieme bedrijven.
Klopt, maar zonder de noodzakelijke kennis trappen veel internetters ook in nepsites waarbij kenners meteen zien dat er van een absurde domeinnaam gebruik gemaakt wordt.

Als je als internetter niet beseft dat de adresbalk van jouw browser meestal veel lastiger te spoofen valt dan de inhoud van de pagina, dan is het al snel lonend om 500.000 semi-willekeurige domeinnamen te registreren - uit https://www.bleepingcomputer.com/news/security/revolver-rabbit-gang-registers-500-000-domains-for-malware-campaigns/ van donderdag:
Revolver Rabbit gang registers 500,000 domains for malware campaigns
By Ionut Ilascu, July 18, 2024 05:30 PM

En voor elk van die domeinnamen krijgen zij -gesponsord door Big Tech- onmiddellijk, gratis en volstrekt anoniem, zoveel DV-certificaten als zij maar willen. Zodat internetters zeker weten dat hun browser een veilige verbinding heeft met een website van een oplichter.
20-07-2024, 18:12 door Erik van Straten
Ook een "grappige", ik kreeg een mailtje van Dela met daarin links die beginnen met:
https://contact dela.nl/optiext/optiextension.dll?ID=<onleesbare_meuk>

Waarom zou ik er niet vanuit moeten gaan dat optiextension.dll naar mijn PC wordt gedownload en wordt gestart (al dan niet middels RunDLL.exe) en al dan niet met als commandline parameter ID=<onleesbare_meuk>?

Overigens zag ik recentelijk dat in Firefox Nightly voor Android (net als al lang in Safari onder iOS en iPadOS), uitsluitend nog de domeinnaam van de website in de adresbalk wordt getoond. Ik zie vóórdelen en nadelen.

Hoe denken de lezers van security.nl hierover?
20-07-2024, 19:47 door Anoniem
Door Erik van Straten: Ook een "grappige", ik kreeg een mailtje van Dela met daarin links die beginnen met:
https://contact dela.nl/optiext/optiextension.dll?ID=<onleesbare_meuk>

Waarom zou ik er niet vanuit moeten gaan dat optiextension.dll naar mijn PC wordt gedownload en wordt gestart (al dan niet middels RunDLL.exe) en al dan niet met als commandline parameter ID=<onleesbare_meuk>?

Je geeft het zelf al aan, er is rundll nodig een bepaalde functie in een DLL te starten. Op zichzelf doet downloaden van een bestand niets, tenzij er aan de clientkant een automatisch lezen of openen plaatsvind als je de folder opent waar het bestand staat. Dat kan bijvoorbeeld gebeuren met Office bestanden, plaatjes. Het is heel handig voor een bepaalde categorie aanvallers als er in zo'n bestand een zero day aanwezig is.

Niettemin leidt het overdreven waarschuwen voor het openen van links niet tot een goed begrip van de werkelijk gevaarlijke handelingen zoals invullen van gegevens op phishing pagina's of het uitvoeren van bestanden.

Overigens zag ik recentelijk dat in Firefox Nightly voor Android (net als al lang in Safari onder iOS en iPadOS), uitsluitend nog de domeinnaam van de website in de adresbalk wordt getoond. Ik zie vóórdelen en nadelen.

Hoe denken de lezers van security.nl hierover?

Gewoon volledig weergeven. Het "verdommen" (dommer maken) is uiteindelijk nadelig voor security. Het begon ooit al met het niet meer weergeven van extensies en ook op deze site wordt een relatieve tijd gebruikt voor postings in plaats van een absolute tijd. Zo wordt het refereren naar berichten onduidelijk.
20-07-2024, 21:35 door Anoniem
Dank Erik, voor je overzicht.
Weer een prima stuk
Ook herhalingen zijn voor mij belangrijk.

Noob
21-07-2024, 02:20 door Erik van Straten
Door Anoniem:
Door Erik van Straten: Ook een "grappige", ik kreeg een mailtje van Dela met daarin links die beginnen met:
https://contact dela.nl/optiext/optiextension.dll?ID=<onleesbare_meuk>

Waarom zou ik er niet vanuit moeten gaan dat optiextension.dll naar mijn PC wordt gedownload en wordt gestart (al dan niet middels RunDLL.exe) en al dan niet met als commandline parameter ID=<onleesbare_meuk>?

Je geeft het zelf al aan, er is rundll nodig een bepaalde functie in een DLL te starten. Op zichzelf doet downloaden van een bestand niets, tenzij er aan de clientkant een automatisch lezen of openen plaatsvind als je de folder opent waar het bestand staat.
Ten eerste: "binary planting" (zie bijvoorbeeld https://attack.mitre.org/techniques/T1574/001/).

Als het openen van de Dela URL een kwaadaardige DLL zou downloaden, ook als die vervolgens niet meteen gestart wordt (DLL's lijken overigens zeer veel op EXE bestanden, de eerste twee bytes zijn bijv. ook "MZ"), is dat toch gevaarlijk. Wellicht nauwelijks met de bestandsnaam optiextension.dll, maar zeker wel met bijv. de naam kernel32.dll (*).

(*) Zie de bovenste tabel in https://www.researchgate.net/figure/List-of-the-top-ranked-30-DLL-names-by-calling-frequency_tbl2_255787076.

Als de internetter later een programma downloadt naar dezelfde map (of dat eerder al gedaan heeft, of bijv. een ZIP bestand in die download map heeft uitgepakt) en dat nu start, is de kans zeer groot dat er code in de kwaadaardige DLL wordt uitgevoerd. De reden daarvoor is dat nagenoeg alle programma's eerst in de map waarin de EXE staat zoeken naar benodigde DLL's.

Ten tweede: Genoemde soort URL's, maar ook vele anderen, dragen alleen maar bij aan mogelijke verwarring bij internetters. Het is techniek bedacht door techneuten, zonder rekening te houden met menselijke gebruikers van die techniek.

Een voorbeeld:
(1) https://github.com/security-alliance/advisories/blob/main/2024-07-squarespace.pdf
(2) https://github.com/security-alliance/advisories/raw/main/2024-07-squarespace.pdf

Als je (1) opent, probeert Github zelf het PDF-bestand te renderen in een deel van de pagina. De browser verwerkt dus html (en Javascript, CSS, plaatjes etc. - die allemaal worden gedownload, meestal naar een cache-map of database gebruikt door de browser).

Als je (2) opent, wordt https://raw.githubusercontent.com/security-alliance/advisories/main/2024-07-squarespace.pdf gedownload (wél een PDF bestand, echter -onverwacht- vanaf een heel andere server, eentje waarop ook veel malware wordt gehost). Vervolgens hangt het van de gebruikte browser af of die browser zelf de PDF (zonder jou iets te vragen) rendert (uitleest en toont zoals bedoeld), óf dat de browser (meestal nadat je hebt bevestigd dat je dat wilt) het PDF bestand downloadt naar de gebruikelijke "Downloads" map - waarbij je meestal ook voor een andere map kunt kiezen.

Oftewel: je kunt aan een URL absoluut niet zien wat er gaat gebeuren als je deze opent. Ooit was .html de gebruikelijke extensie voor webpagina's, en niet lang daarna volgden .php en .asp[x] (die laatste twee met grote impact voor "server side"). Op de meeste websites zijn dergelijke extensies geheel verdwenen.

Dat je als internetter maar moet afwachten wat er gaat gebeuren als je een link ziet en deze opent, vind ik STOM en gebruikersonvriendelijk. Net als ego's die in het verkeer (o.a. bij het verlaten van rotondes) geen richting aangeven terwijl dat verplicht is: "je komt er vanzelf wel achter wat er gaat gebeuren".

Op zich slim van Microsoft om bijv. Excel bestanden voorzien van macro's de extensie .xlsm te geven. Maar weer totaal zinloos omdat bestandsextensies standaard niet getoond worden, en je ook macro's in Excel bestanden met andere extensies kunt opnemen.

Het is allemaal zó extreem ondoordacht. Internetters en andere computeraars wordt (vaak uiterst) zinvolle informatie onthouden, zogenaamd om het e.e.a. "gebruiksvriedelijker' te maken. Maar dat is kul: er is niets gebruiksvriendelijk aan een gecompromiteerde PC of draagbaar device, laat staan dat je bankrekening geplunderd wordt. Essentiële informatie weglaten is voor iedereen een ramp, vooral voor gebruikers die wél de moeite hebben genomen om (feitelijk voor iedereen minimaal noodzakelijke) kennis te vergaren.

Door Anoniem: Dat kan bijvoorbeeld gebeuren met Office bestanden, plaatjes. Het is heel handig voor een bepaalde categorie aanvallers als er in zo'n bestand een zero day aanwezig is.
Niet in het bestand zelf, maar de verwerker. Waaronder een kwetsbaarheid in een driver voor de grafische kaart in je PC (code die meestal met hoge privileges draait) zoals CVE-2024-0090.

Door Anoniem: Niettemin leidt het overdreven waarschuwen voor het openen van links [...]
Vooral niet open deuren zoals "Klik niet zomaar op een link" of "Klik niet op onbetrouwbare links".

Door Anoniem: [...] niet tot een goed begrip van de werkelijk gevaarlijke handelingen zoals invullen van gegevens op phishing pagina's of het uitvoeren van bestanden.
Exact.

Door Anoniem:
Overigens zag ik recentelijk dat in Firefox Nightly voor Android (net als al lang in Safari onder iOS en iPadOS), uitsluitend nog de domeinnaam van de website in de adresbalk wordt getoond. Ik zie vóórdelen en nadelen.

Hoe denken de lezers van security.nl hierover?

Gewoon volledig weergeven. Het "verdommen" (dommer maken) is uiteindelijk nadelig voor security. Het begon ooit al met het niet meer weergeven van extensies en ook op deze site wordt een relatieve tijd gebruikt voor postings in plaats van een absolute tijd. Zo wordt het refereren naar berichten onduidelijk.
Dank voor jouw mening hierover. Aangezien er URL's zijn met zeer zinvolle info daarin (hiërarchie, datum-aanduiding, ...), naast het type dat uit -voor mensen- onbegrijpelijke wartaal bestaat (bijv. https://open.overheid.nl/documenten/dpc-689d7945030622dff1af19431c3ccd5053af163c/pdf (+) ), twijfel ik.

Vanuit security-oogpunt is er beslist wat voor te zeggen dat internetters primair op de domeinnaam moeten focussen.

(+) Terzijde: https://open.overheid.nl/documenten/dpc-689d7945030622dff1af19431c3ccd5053af163c/ geeft een
onverwachte foutmelding, terwijl https://open.overheid.nl/documenten/dpc-689d7945030622dff1af19431c3ccd5053af163c interessante info oplevert.
En daaruit afgeleid, door in Firefox/Android https://open.overheid.nl/documenten/dpc-689d7945030622dff1af19431c3ccd5053af163c/_text te openen, wordt een bestand genaamd _tekst.bin gedownload - dat platte tekst uit de PDF bevat. Moeilijker kunnen we het nauwelijks maken.
21-07-2024, 08:48 door Anoniem
Door Erik van Straten:
Door Anoniem:
Door Erik van Straten: Ook een "grappige", ik kreeg een mailtje van Dela met daarin links die beginnen met:
https://contact dela.nl/optiext/optiextension.dll?ID=<onleesbare_meuk>

Waarom zou ik er niet vanuit moeten gaan dat optiextension.dll naar mijn PC wordt gedownload en wordt gestart (al dan niet middels RunDLL.exe) en al dan niet met als commandline parameter ID=<onleesbare_meuk>?

Je geeft het zelf al aan, er is rundll nodig een bepaalde functie in een DLL te starten. Op zichzelf doet downloaden van een bestand niets, tenzij er aan de clientkant een automatisch lezen of openen plaatsvind als je de folder opent waar het bestand staat.
Ten eerste: "binary planting" (zie bijvoorbeeld https://attack.mitre.org/techniques/T1574/001/).

Als het openen van de Dela URL een kwaadaardige DLL zou downloaden, ook als die vervolgens niet meteen gestart wordt (DLL's lijken overigens zeer veel op EXE bestanden, de eerste twee bytes zijn bijv. ook "MZ"), is dat toch gevaarlijk. Wellicht nauwelijks met de bestandsnaam optiextension.dll, maar zeker wel met bijv. de naam kernel32.dll (*).

(*) Zie de bovenste tabel in https://www.researchgate.net/figure/List-of-the-top-ranked-30-DLL-names-by-calling-frequency_tbl2_255787076.

Als de internetter later een programma downloadt naar dezelfde map (of dat eerder al gedaan heeft, of bijv. een ZIP bestand in die download map heeft uitgepakt) en dat nu start, is de kans zeer groot dat er code in de kwaadaardige DLL wordt uitgevoerd. De reden daarvoor is dat nagenoeg alle programma's eerst in de map waarin de EXE staat zoeken naar benodigde DLL's.

Een nuancering:

De beschreven werkwijze werkt standaard alleen op een windows OS.

Voor linux, apple en android moet je eerste een emulator (wine oid) installeren voordat je met dll's en exe's kunt werken.
21-07-2024, 12:59 door Erik van Straten
Door Anoniem: Een nuancering:

De beschreven werkwijze werkt standaard alleen op een windows OS.
Alleen wordt er geen DLL gedownload bij de Dela URL die ik noemde.

Ik probeerde te laten zien dat internetters terecht zouden kunnen denken dat er een DLL zal worden gedownload.

En dus dat dit soort URL's internetters ontmoedigen om ernaar te kijken: het is voor de meeste mensen nietszeggende wartaal vooral bedoeld voor computers (en evt. voor foutmeldingen onderzoekende beheerders).

En dát kan averechts werken, wetende dat het meestal essentieel is om ervan verzekerd te zijn dat je naar de bedoelde website zit te kijken - voordat je vertrouwt wat je leest, iets downloadt of vertrouwelijke gegevens invoert.

Vanuit dát perspectief is het prima dat meer browsers, vooral die met relatief korte (qua aantal leesbare karakters) adresbalken, de URL strippen tot het essentiële deel van de domeinnaam (dus ook "www." weglaten).

Niet alleen Windows
Daarnaast kan elke website mogelijk RCE veroorzaken, uit https://nvidia.custhelp.com/app/answers/detail/a_id/5551/~/security-bulletin%3A-nvidia-gpu-display-driver---june-2024 (een website van een derde partij waar je naartoe verwezen wordt als je in https://www.nvidia.com/en-us/security/ op "NVIDIA® GPU Display Driver - June 2024" klikt waarbij rechts daarnaast "5551"staat):
NVIDIA GPU driver for Windows and Linux contains a vulnerability where a user can cause an out-of-bounds write. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

Vergelijkbare kwetsbaarheden zijn er telkens in elk besturingssysteem (ook OS X, Android en iOS/iPadOS), zowel in "eigen" als in third party code.

In de praktijk zijn de risico's bij Windows wél veel groter, omdat er nog steeds heel veel gebruikers van zijn, Microsoft altijd "gebruiksvriendelijkheid" (verhullen van complexiteit) vóór liet gaan op security, en de gigantische berg (vaak totaal verouderde, en met veel wederzijdse afhankelijkheden - hetgeen tot een enorme complexiteit leidt) "features" die bijna niemand allemaal gebruikt. Maar die Microsoft niet uit durft, wil en/of kan uitzetten zolang het aantal gebruikers groter dan nul is (ze doen er vaak jaaaaren over voordat zij eindelijk aankondigen om irreparabel kwetsbare code en/of protocollen te disablen en/of te vervangen, om vervolgens -in veel gevallen- dat moment meerdere keren uit te stellen).

Hoe lomper de codebase en hoe meer gebruikers, hoe groter de risico's. Als de meeste mensen OS X of Linux hadden gebruikt, zouden de risico's bij het gebruik van die besturingssystemen nu véél groter zijn geweest. Precies daarom, en omdat vooral meer ervaren gebruikers voor "moeilijker" besturingssystemen kiezen, heb ik zo'n bloedhekel aan het kortzichtige "mijn OS is beter want minder slachtoffers" argument.
21-07-2024, 13:47 door Anoniem
Door Erik van Straten:
Door Anoniem: Een nuancering:

De beschreven werkwijze werkt standaard alleen op een windows OS.
Alleen wordt er geen DLL gedownload bij de Dela URL die ik noemde.

Ik probeerde te laten zien dat internetters terecht zouden kunnen denken dat er een DLL zal worden gedownload.

En dus dat dit soort URL's internetters ontmoedigen om ernaar te kijken: het is voor de meeste mensen nietszeggende wartaal vooral bedoeld voor computers (en evt. voor foutmeldingen onderzoekende beheerders).

En dát kan averechts werken, wetende dat het meestal essentieel is om ervan verzekerd te zijn dat je naar de bedoelde website zit te kijken - voordat je vertrouwt wat je leest, iets downloadt of vertrouwelijke gegevens invoert.

Vanuit dát perspectief is het prima dat meer browsers, vooral die met relatief korte (qua aantal leesbare karakters) adresbalken, de URL strippen tot het essentiële deel van de domeinnaam (dus ook "www." weglaten).

Niet alleen Windows
Daarnaast kan elke website mogelijk RCE veroorzaken, uit https://nvidia.custhelp.com/app/answers/detail/a_id/5551/~/security-bulletin%3A-nvidia-gpu-display-driver---june-2024 (een website van een derde partij waar je naartoe verwezen wordt als je in https://www.nvidia.com/en-us/security/ op "NVIDIA® GPU Display Driver - June 2024" klikt waarbij rechts daarnaast "5551"staat):
NVIDIA GPU driver for Windows and Linux contains a vulnerability where a user can cause an out-of-bounds write. A successful exploit of this vulnerability might lead to code execution, denial of service, escalation of privileges, information disclosure, and data tampering.

Vergelijkbare kwetsbaarheden zijn er telkens in elk besturingssysteem (ook OS X, Android en iOS/iPadOS), zowel in "eigen" als in third party code.

In de praktijk zijn de risico's bij Windows wél veel groter, omdat er nog steeds heel veel gebruikers van zijn, Microsoft altijd "gebruiksvriendelijkheid" (verhullen van complexiteit) vóór liet gaan op security, en de gigantische berg (vaak totaal verouderde, en met veel wederzijdse afhankelijkheden - hetgeen tot een enorme complexiteit leidt) "features" die bijna niemand allemaal gebruikt. Maar die Microsoft niet uit durft, wil en/of kan uitzetten zolang het aantal gebruikers groter dan nul is (ze doen er vaak jaaaaren over voordat zij eindelijk aankondigen om irreparabel kwetsbare code en/of protocollen te disablen en/of te vervangen, om vervolgens -in veel gevallen- dat moment meerdere keren uit te stellen).

Hoe lomper de codebase en hoe meer gebruikers, hoe groter de risico's. Als de meeste mensen OS X of Linux hadden gebruikt, zouden de risico's bij het gebruik van die besturingssystemen nu véél groter zijn geweest. Precies daarom, en omdat vooral meer ervaren gebruikers voor "moeilijker" besturingssystemen kiezen, heb ik zo'n bloedhekel aan het kortzichtige "mijn OS is beter want minder slachtoffers" argument.

Kalm. Rustig blijven.
Dat zei ik niet.

Ik citeerde jouw eigen "zou" uitleg:

Als de internetter later een programma downloadt naar dezelfde map (of dat eerder al gedaan heeft, of bijv. een ZIP bestand in die download map heeft uitgepakt) en dat nu start, is de kans zeer groot dat er code in de kwaadaardige DLL wordt uitgevoerd. De reden daarvoor is dat nagenoeg alle programma's eerst in de map waarin de EXE staat zoeken naar benodigde DLL's.

En dat is wel specifiek Windows.
Die andere OSen ondersteunen die uitvoerbare exe (default) niet, dus kan het betreffende OS er niets mee.
Meer probeerde ik niet te zeggen.

Daarmee claim ik helemaal niet dat andere OS-en beter zijn. Verre van dat. (Die nutteloze welles/nietes discussie wil ik juist vermijden)
Met een andere aanvalshoek kan het ook bij andere OS-en verkeerd gaan. Dat ben ik met je eens.
Maar die aanvalshoek beschreef je niet (in je eerdere post).
Ik gaf alleen maar een verduidelijking voor lezers die minder thuis zijn in dat soort verschillen.
Gisteren, 14:24 door EKTB
Wie bankiert tegenwoordig nog bij Bunq?
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet 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.