Waar?

Bijzonder dat de conclusie is om vooral meer monitoring en detectie af te nemen, in plaats van het toepassen van DNSSEC validatie. Dat laatste zou de impact van de aanval beperken van besmette updates tot een beschikbaarheid probleem.

Ja blijft jammer dat er binnen Windows niet een algemeen geaccepteerde en gebruikte manier is om updates te installeren!
Het is aan iedere applicatie om een updater in te bouwen en niet iedereen doet dat even zorgvuldig natuurlijk.

Hoe effectief is dat hier? Bij een besmette DNS server bij de ISP zijn alle DNS responses toch te manipuleren, waardoor het voor de client lijkt of betreffend domein niet dnssec enabled is.

De controle die de software uitvoert verliep via http in plaats van https? Hoe is dat mogelijk in 2024. Zou het OS niet gewoon https moeten afdwingen, zoals iOS dat al wat jaren doet?

terug in de middeleeuwen ljikt het wel "Het ging hierbij specifiek om applicaties die automatische updates via HTTP uitvoeren en de digitale handtekening van de update of installer niet goed controleren.".

De aanvallers werken voor de Chinese overheid en het doelwitten zijn in Hong Kong, Maleisie, Macao, Taiwan, India, NGO's in China, etc.

Evasive Panda/Pocostick
https://www.welivesecurity.com/2023/04/26/evasive-panda-apt-group-malware-updates-popular-chinese-software/

Eerst kijken, dan pas zeiken. Dit staat toch echt in de tekst:

Aha! Dank!

Dan blijft GNU+Linux over.

Die is er inmiddels, en dat heet de windows app store.

eerst eens nadenken en dan pas posten?

Een applicatie die z'n update-domein keihard vastlegt beperkt verplicht zich daarmee om een voldoende groot CDN te leveren voor alle update clients .

Google (voor chrome, android) en Microsoft e.d. kunnen dat .

Maar zie dat bijvoorbeeld Debian (e.a.) simpelweg 'iedereen' een mirror laat zijn - met of zonder https .
De debian (en ubuntu, etc etc) updates kunnen niet hardcoden wat 'echte' mirrors zijn , want die kunnen er bij komen (of verdwijnen)
Die doen de check op de updates zelf, en dat is een prima methode.

Nu is de garantie van https ook niet _zo_ sterk, met de massa aan CAs van soms twijfelachtige kwaliteit .

Dat gebruikt geen hond - en de applicatie die gecompromitteerd werd zal er wel niet voor bestaan.

Verder - als je de gebruiker 'gewoon' een dpkg/rpm laat installeren van een malicious repo gaat dat op precies dezelfde manier mis.

'trust new gpg key' Y . bingo. Als er al een key bij zit.

Ik zal maar weer een flink vloeken in de kerk : Apple , met een gecontroleerde app store en zonder side loading WINT gewoon . Niks is perfect - maar beter dan al die platformen met 'empowered users' die dat niet snappen.

Ik heb even gekeken op mijn netwerk. Ik had altijd mijn DNS ingesteld op 1.1.1.1, en 8.8.8.8... maar is dit ook ipv6 gebeurd dan? Want om de een of andere reden heeft de router van mijn isp de dns server gereset naar hun dns servers. Waarom? En waar is dit allemaal gebeurd? Welke applicaties?

Dat is helemaal niet nodig. Je kunt prima je updates over http inladen als ze dan daarna maar wel gecontroleerd worden op een geldig signature.
En dat moet je evengoed wel doen, dus eigenlijk is het overbodig om https te gebruiken.

Twee reacties die vinden dat https niet nodig is, terwijl dat de aanvalsvector mogelijk heeft gemaakt. Lees je even in aub. Http is onveilig, omdat het AitM mogelijk maakt.

Je wilt ook op je eigen caching DNS server DNSSEC validatie uitvoeren. Als je blind vertrouwd op de DNS server van de ISP, dan gaat het al verkeerd.

Een mannetje in het midden op netwerkniveau kan in principe alle (hier DNS) traffic ongemerkt doorgeleiden naar een andere server. Daar merk je niets van, behalve als er ergens authenticatie plaatsvind.

Apple? Nee, die heeft een gesloten systeem, een fabrikant "vertrouwen" is nooit goed, vertrouw alleen de code.
Daarnaast doet Apple een hoop first party spying, in China is iCloud in handen van de Chinese overheid.
Ask not to track is een manier om ads te monopoliseren.
Apple is begonnen over client side scanning.
Apple is een zwarte gesloten doos, we weten niet wat er zich daar achter afspeelt, wel weet ik dat demonstranten uit Hong Kong opzettelijk door Apple zijn beperkt, en dankzij hun walled prison zijn er geen alternatieven mogelijk.
Apple is een walgelijk bedrijf.

Het is inderdaad niet voor honden bedoeld maar voor mensen.
En het feit dat weinig mensen het gebruiken neemt niet weg dat het een goed systeem is.
En ja, iedereen kan opzettelijk spyware installeren, maar de meeste GNU+Linux distributies hebben hun eigen application repository (een soort appwinkel) met voornamelijk vrije software, erg veilig.
Apple geeft de gebruiker daarentegen geen keuze en heeft volledige macht over haar gebruikers.
GNU+Linux is transparant vanwege haar vrije licentie en open bron.
Men kan daarnaast een immutable distributie installeren waarbij er alleen lees-toegang tot het systeemgeheugen is.
Ook de manier waarop GNU+Linux in elkaar zit maakt het inherent veiliger.
Geen enkel systeem is waterdicht, maar het is een zeer goede keuze.

Waf-Waf. Ik gebruik linux wel.
En met mij ook anderen.

Verder wordt linux/unix ook veel gebruikt als OS voor servers.

Dan is alleen de uitwisseling van de data van en naar de applicatie beveiligd. In dit geval was de bron van de updates te beïnvloeden. In theorie is het zelfs mogelijk om valse certificaten te bemachtigen als je controle over de dns omgeving hebt.

Inderdaad, als je het niet erg vindt dat Apple voor je bepaalt wat goed voor je is dan zit je goed bij Apple.

Nee de aanval was mogelijk door: "Het ging hierbij specifiek om applicaties die automatische updates via HTTP uitvoeren en de digitale handtekening van de update of installer niet goed controleren."
M.a.w. het probleem zit in de updater, die moet goed controleren of wat er aangeboden wordt wel een geldige update is.
Een probleem in Windows is dat iedereen zijn eigen updater moet maken ipv dat er 1 centrale updater is die alle applicaties bedient.
Daardoor is de kans groter dat er ergens een rotte appel tussen zit.

Gaat richting de 5% al.

Dat weet ik. Ik gebruik het zelf ook.

Ik ben alleen niet zo'n leipe fanboy die gelooft dat een gemiddelde gebruiker op Linux dit probleem niet zal hebben.

Omdat die gemiddelde gebruiker doodgewoon op Y gaat klikken als er zo'n raar technisch verhaal staat van 'gpg key' met een enorm aantal rare cijfers.

Die fanboys hier willen maar niet zien dat DAT DAT GEEN OPLOSSING IS. Zolang het maar voor hun clubje super elite technerds 'beter' is omdat ze alles lekker kunnen tweaken en compileren en keyserver halen en web of trust en zo'n lekker warm gevoel dat ze zo super veilig bezig zijn.
AL die aanvallen hebben niks met techniek te maken - en alles met gebruikers die op platform zitten waarop ze alles zelf MOETEN beslissen omtrent installaties, trust en acceptatie - of daar met minimale moeite mee 'geholpen' kunnen worden (zoals 3rd party repo's).
En dat is gewoon de definitie van een (zelf beheerde) Linux : je MOET alles zelf beslissen. Want de technerds willen maximale controle en geven overal een tweak , een knop en een optie voor, en de gui pompt dat braaf in een dialoog scherm.
En dat gaat dan voor 99% van de 'gewone gebruikers' (als die per ongeluk op Linux gekomen zijn) net zo hard mis als wanneer ze op Windows zitten.


Windows heeft natuurlijk hetzelfde probleem, en ook Android (met sideloading opties, en deels met een google app store die wat minder fanatiek gecontroleerd is dan Apple doet voor de hunne) is niet helemaal immuun.

Maar dat is het PICNIC probleem. Dat los je nooit op zonder die gemiddelde gebruikers te veranderen.

Dat soort "gemiddelde" gebruikers kan zelfs op een volledig dicht getimmerd systeem nog stunts uithalen waar geen enkele beheerder of leverancier aan gedacht heeft. Ongeacht of het OS een Windows, Android, Linux of iOS smaak heeft.
Gewoon omdat ze ondoordacht op hun knopjes drukken. Wat het scherm ook zegt.
En dan hebben we het nog niet over de echte digibeten. Die zijn nog verder van huis.

Apple _heeft_ dat aardig opgelost , gewoon doordat er geen knopjes ZIJN om waarmee de gebruiker ongecontroleerd software kan installeren.

Linux (en Windows) hebben nu juist als religie dat ALLES instelbaar en wijzigbaar moet zijn door een gebruiker.


Gecombineerd met een trusted app store en een vrij goed werkend controle proces maakt dat malware op IOS , en zeker malware die andere applicaties kan overnemen gewoon heel erg zeldzaam.

De voornaamste vector die overblijft is het manipuleren van de gebruiker om zelf, met een valide applicatie en valide credentials , dingen te doen die een crimineel wil (zoals geld overschrijven naar een rekening ).

Maar het 'installeren' van malicious apps door misleide gebruikers - en malicious apps die 'het platform' overnemen omdat de gebruiker ze daartoe de rechten geeft - zijn in het iOS landschap gewoon amper een probleem .
En dat is _omdat_ de gebruiker er gewoon weinig rechten heeft om (bewust of misleid) het platform te managen.
Natuurlijk is dat tegen het zere been van alle werkelijke (of zelf benoemde) powertweaker users .


Die zijn echt beter af met Apple. (telefoon en tablet). Een heleboel technische dreigingen bestaan dan gewoon niet.

Laat dit nu net de grootste dreiging zijn. De kans op een aanval via een besmette app is vele malen kleiner, op welk OS je ook zit. Dan kan het zijn dat Apple die 1% kans naar 0,1% weet te minimaliseren, dan betekent het nog steeds dat het een druppel op de gloeiende plaat is.

Maar ja, als je teveel wil betalen, het niet erg vindt om in een gesloten systeem te zitten, dan zou je Apple kunnen overwegen.

Er zijn teveel redenen om Apple absoluut niet te vertrouwen (zie videos hieronder)
Daarnaast is het beter om een "zero-trust" polucy aan te nemen waarbij je niemand hoeft te vertrouwen, maar in plaats daarvan men het bewijst via transparantie van code en vrije licenties.

The Hated One videos over Apple:

Apple Is Terrible for Your Privacy
https://youtu.be/r38Epj6ldKU

How Tim Cook Surrendered Apple to the Chinese Government
https://youtu.be/Ev9_oDHNf-4

Actually! Android is more private than the iPhone!
https://youtu.be/nQ9LR8homt4

Don't Believe Apple's Privacy Grandstanding
https://youtu.be/shxTTon5lfs

Apple and Google contact tracing is a dystopian nightmare
https://youtu.be/WRalTWAFBY4

Do NOT trust Apple Intelligence!
https://youtu.be/6YbeGjnqEZ8

Korte link naar deze reactie: https://security.nl/posting/852763.

Klopt.

Sterker, https is, indien de server en de browser zich aan de regels houden, ijzersterk in het voorkómen dat een AitM zich in één E2EE https verbinding tussen browser en server weet te nestelen. De vraag is wel wat je daar aan hebt als er minstens drie situaties bestaan waardoor AitM's met twee of meer https verbindingen mogelijk zijn:
• Onterecht uitgegeven DV-certificaten
• Mensen incompatibel met domeinnamen
• "Legitieme" AitM's

Zie https://crt.sh/?id=13897808125&opt=ocsp voor het volgende voorbeeld:

De incompatibiliteit van mensen met domeinnamen is een véél groter (maar oplosbaar) probleem dan
onterecht uitgegeven DV-certificaten (verderop geef ik voorbeelden van die menselijke incompatibiliteit).

Zie https://crt.sh/?q=m-santander.de voor het volgende voorbeeld:

Het vorige plaatje is feitelijk onjuist, want de genoemde aanvaller verstopt zich achter Cloudflare (zie https://www.virustotal.com/gui/domain/m-santander.de/details). Het correcte plaatje ziet er waarschijnlijk uit als volgt:
Overigens weet je niets over verbinding #2 (welk servercertificaat gebruikt wordt, mogelijk gebruikt die verbinding niet eens https).

Een domeinnaam, zoals drogist.nl of www.ing.nl, is een identifier waarmee bijvoorbeeld een internet-website uniek geadresseerd kan worden.

Feitelijk is zo'n domeinnaam een alias - waaruit geenszins hoeft te blijken wie de "eigenaar" is van de website (zoals in het eerste geval).

In de basis is een domeinnaam een alias voor een IP-adres, vergelijkbaar met een naam (of nickmame) en een bijbehorend telefoonnummer in een adresboek.

Een domeinnaam kan overigens ook aan meer dan één IP-adres gekoppeld zijn (vergelijkbaar met dat iemand op meerdere telefoonnummers bereikt kan worden).

Omdat (nog steeds zeer gangbare) IPv4 adressen 32 bits lang zijn en er in theorie dus 2^32 = 4.294.967.296 IP-adressen mogelijk. Grote hoeveelheden daarvan vallen, om allerlei redenen, af, hetgeen de schaarste aan IPv4 adressen vergroot. O.a. om die reden "zitten" er vaak meerdere, soms duizenden, websites achter één IPv4 adres.

Domeinnamen voor websites hebben dan een dubbelfunctie:
• Met welk IPv4 adres moet de browser verbinding maken (DNS vraag en antwoord);

• SNI (Server Name Indication): bij het opzetten van de verbinding vertelt de browser aan de server met het via DNS verkregen IP-adres welke website precies bedoeld wordt.

Het probleem hier is dat de meeste domeinnamen feitelijk aliases zijn die niets hoeven te zeggen (of zelfs onterecht suggestief kunnen zijn) ongeschikt zijn "voor menselijke consumptie". De primaire redenen daarvoor zijn:

1) Als mensen iets met een organisatie willen of moeten doen waar zij niet eerder mee te maken hadden (zoals een gegooglede website van een loodgieter of de een of andere webshop (zie bijv. https://security.nl/posting/851829) valt er niets te herinneren aan de domeinnaam van die gevonden website. Die domeinnaam hoeft niets te zeggen over de eigenaar van de website, of kan zelfs suggestief (misleidend) zijn (zoals in het voorbeeld dat ik noemde);

2) Dat mensen niet goed zijn in het 100% foutloos onthouden van potentieel nietszeggende domeinnamen.

Het kan fout gaan als de gebruiker van de browser:

• Vertrouwt op logo's en bijv. KvK-info in webpagina's en de domeinnaan getoond in de adresbalk van diens browser daarom niet checkt;

• De domeinnaam in de adresbalk wél checkt maar niet weet hoe deze te interpreteren (zoals m-santander[.]de, suggererend een mobiele variant van de echte santander.de te zijn - zie https://www.virustotal.com/gui/domain/m-santander.de, of bijvoorbeeld in loginmicrosoftonlinecom.pages[.]dev trapt, zie https://www.virustotal.com/gui/domain/loginmicrosoftonlinecom.pages.dev);

• De domeinnaam in de adresbalk wél checkt maar niet weet dat de betreffende domeinnaam niet toebehoort aan de gesuggereerde eigenaar (zoals ing-movil[.]com, zie https://www.virustotal.com/gui/domain/ing-movil.com);

• De domeinnaam in de adresbalk wél checkt maar zich niet herinnert dat een streepje (minnetje) niet in de authentieke domeinnaam voorkwam, zoals destijd bij circle-ci.com (nep) en circl-ci.com (authentiek) - zie https://security.nl/posting/768888. Of zich niet realiseert dat dydx.exchange niet van dezelfde eigenaar hoeft te zijn als bijvoorbeeld dxdy.exchange of dydx.finance;

• De domeinnaam in de adresbalk wél checkt maar zich niet herinnert dat de exacte TLD van de authentieke domeinnaam een andere was (zoals ik hierboven noemde), of bijvoorbeeld example.co.com verwart met example.com.co;

• De domeinnaam in de adresbalk wél checkt maar zich laat foppen met een "lijkt op" IDN - een groter risico naarmate de ogen van de internetter slechter zijn. Zelf heb ik ook een leesbril nodig waarvan ik er ééntje bij mijn moeder heb laten liggen. Toegegeven, met 95 Eurocent bij de Action ook weer geen economische ramp, mits je niet te veel "cylinder" hebt (= astigmatisme, het brandpunt in bijvoorbeeld verticale richting verder weg of dichterbij dan in horizontale richting). Ook dyslexie bemoelijkt het correct lezen van domeinnamen. Overigens hoeven er in IDN's geen zichtbare afwijkingen t.o.v. ASCII karakters te zien zijn.

Als je in Firefox bijvoorbeeld https://www.xn--80ak6aa92e.com/ (dat wordt Punycode genoemd) opent, zie je in de adresbalk (naast het hangslotje) gewoon apple.com (de IDN = International Domain Name - dat andere browsers de Punycode i.p.v. de IDN tonen, komt doordat zo'n IDN -met vertraging- op een blocklist is gezet en/of de browser van -potentieel- feilbare "AI" gebruikmaakt). Een ander voorbeeld is https://xn--hopfenhhle-kcb.de, dat de meeste (zo niet alle) browsers wél als hopfenhöhle.de (bierkoeler!) laten zien;

• De domeinnaam in de adresbalk wél checkt maar niet ziet dat deze veel langer is (Firefox onder Android toont dan het minder interessante linkerdeel van de domeinnaam, check bijvoorbeeld (niet bereikbaar via https) http://klusbedrijf-constructiewerk-onderhoud-renovatie-keuken-badkamer.nl/ (bron: https://www.sidn.nl/en/news-and-blogs/whats-the-longest-domain-name uit 2018; veel links zijn dood en zo te zien ondersteunt geen enkele https). Hoe langer het op naam gezette deel van een domeinnaam is, hoe stommer de registreerder, en hoe onveiliger diens website wel eens zou kunnen zijn;

• De domeinnaam in de adresbalk wél checkt maar niet weet dat deze niet van de bedoelde webserver is, maar van een potentieel onbetrouwbare CDN-operator (zoals Cloudflare en Fastly) terwijl vertrouwelijke informatie moet worden uitgewisseld die de three letter agencies van de USA niet beslist niet te weten mogen komen;

• De domeinnaam in de link waar zij of hij op klikt wél checkt, maar niet ziet dat deze een @ bevat, zoals in https://nu.nl@nos.nl (security.nl maakt die link niet klikbaar, maar sommige browsers openen daarmee nos.nl zonder te waarschuwen);

• De domeinnaam in de link waar zij of hij op klikt wél checkt, maar niet ziet dat deze een 'l' i.p.v. een 'I' bevat (of andersom). Denk ook aan 'vv' versus 'w' en 'rn' versus 'm', en zo zijn er meer verwarringen mogelijk;

• De domeinnaam in de link waar zij of hij op klikt wél checkt, maar niet weet dat/of het om een (soort) URL-shortener service gaat, zoals in https://tiny.cc/KvK-Klarna (te vinden verderop in de pagina https://tiny.cc/Klarna-Aflossen), of bijv. https://i5c.us/d31136 (zie https://infosec.exchange/@sans_isc/112887855671019627 en mijn reactie daaronder);

• De domeinnaam in de link waar zij of hij op klikt wél checkt, maar niet weet dat/of het om een open redirect gaat;

• De domeinnaam in de link waar zij of hij op klikt wél checkt, maar niet beseft dat/of het om een closed redirect gaat, zoals een (lange en nauwelijks "leesbare") link zoals https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.foodwatch.org%2Fnl%2Fcurrent-nieuws%2F2021%2Flandbouwgif-glyfosaat-in-wijn-van-ah-jumbo-en-lidl%2F&data=05%7C01%7Cviolette.geissen%40wur.nl%7C24b9c627a60e445c9c8808da255f98d7%7C27d137e5761f4dc1af88d26430abb18f%7C0%7C0%7C637863389784658423%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hH9tTaPiHX6ZwtQoEqaV3onA2IAfG2GnPIgDFR%2BgLJk%3D&reserved=0 (de laatste link in de tekst van https://www.rtl.nl/nieuws/nederland/artikel/5411313/glyfosaat-hoe-een-als-veilig-beoordeeld-bestrijdingsmiddel-nu-toch).

• En wat ik nu vergeet.

Domeinnamen zijn een onmenselijke, en vooral in mobiele browsers krampachtige, "oplossing" om websites uniek mee te adresseren - zonder dat zij betrouwbare informatie over de eigenaar van een website geven. Dat mensen hier in de praktijk betrouwbaar gebruik van zouden kunnen maken, is ordinair wensdenken door techsolutionisten.

Een prima oplossing is denkbaar (https://security.nl/posting/852741), maar naast dat Big Tech dat (om financiële redenen) niet wil, reageren op deze site ook criminelen, anarchisten en/of niet-snappende egoïsten negatief op mijn voorstellen van dit type.

Wat je blijkbaar ontgaan is de laatste jaren : toen desktop OSen nog het dominante platform waren voor alles (en internet bankieren) was "technische malware" de norm. Banking trojans in alle soorten en maten - natuurlijk voor het dominante desktop platform, waarop dit ook heel goed mogelijk en makkelijk was (zonder of met enige hulp van de gebruiker) - volledig automatisch oogsten.

Het heeft pas _moeten_ verschuiven naar de veel interactievere (dus lastiger/langzamer/duurder) persoon-gerichte manipulatie met de opkomst van onzettend veel veiliger platformen voor bankieren . (namelijk mobiele devices. Ook Android is al erg veel veiliger dan een gewone desktop)

Echt, de verbetering vind plaats voor je ogen , maar mensen blijven vastgeroest in hun beeld.


Ga maar lekker principieel zitten zijn en al je avonden besteden aan het frutten met je voorkeurs systeem. Tijd heeft waarde.
Voor hoeveel Linux gebruikers moet je de persoonlijke helpdesk zijn voor alles en niks ?

Niet alle TLD zones zijn voorzien van DNSSEC.