Tja, altijd en alleen maar kiezen voor open-source is de beste oplossing. Dus ook je router firmware naar open source zoals dd-wrt etc. Ook apps moet je rekening houden, f-droid store bevat allemaal open source apps. Zelfs je os, altijd kiezen voor open source, dus linux nemen dan.

Of je kan ook zeggen "ik heb niets te verbergen", wat de meesten doen.

Een digitale handtekening is meestal veel veiliger dan een hash op een website, mits volstrekt duidelijk is wie die digitale handtekening heeft gezet en jij die persoon of organisatie vertrouwt - inclusief hun signing proces (dat ging bijv. mis bij Piriform met CCleaner, en eerder bij Adobe). Om zo'n digitale handtekening te kunnen zetten, moet een aanvaller toegang hebben tot de private key (of tot het signing proces dat toegang heeft tot de private key).

Ik weet niet of je Windows gebruiker bent, maar veel software daarvoor heeft tegenwoordig een Authenticode handtekening. Als ik software download, controleer ik altijd zo'n digitale handtekening. Als die ontbreekt maar bij eerdere versies wel aanwezig was, zit het er dik in dat het goed mis is. Overigens laat Virustotal ook zien of een bestand digitaal ondertekend is en welk certificaat daarbij is gebruikt. Als je eerder software van een persoon of organisatie hebt gedownload, hoort de signing name in het certificaat natuurlijk dezelfde te zijn.

Indien binaries zijn ondertekend met PGP/GnuPG is het ook zeer raadzaam om die signatures te checken, maar dat vereist meer instanning om er zeker van te zijn dat de meegeleverde public key daarwerkelijk van de kennelijke persoon of organisatie is (die dan over de bijbehorende private key moet beschikken).

Wat je ook kunt doen is, na download, enkele dagen wachten met installeren en kijken of anderen problemen melden met datzelfde bestand (of hash daarvan). En dan nogmaals aanbieden op virustotal.

Veel installatiebestanden kun je ook zelf uitpakken (bijv. met 7-Zip of innounp) en onderzoeken met commando's als "strings" of een hex editor, maar dat vereist wel vaardigheden op dit gebied (niet iedereen is een reverse-engineer).

@Anoniem 17:04: open source is alleen maar betrouwbaar als je:
- de sources grondig onderzoekt en doorgrondt wat je ziet
EN
- zelf de binaries bouwt met een betrouwbare ontwikkelomgeving
Ook dat is slechts aan weinigen gegeven.

Met Office365 en Office2016 word je PC via "OfficeClickToRun" voortdurend van updates voorzien (uitsluitend bij internetconnectiviteit natuurlijk), die digitaal zijn ondertekend en via http worden gedownload. Je kunt alleen maar hopen dat Microsoft weet te voorkomen dat aanvallers toegang krijgen tot hun code signing processen.

Hoi, ik ben Vandaag, 17:04 door Anoniem,
Wat jij allemaal verteld is waar, maar veel te moeilijk voor newbies! ;-)
Het is gewoon zo dat er amper virussen compatible zijn in linux. Daarom zeg ik altijd en alleen maar "open source" om de kans toch te verkleinen dat je geinfecteerd geraakt.

Dat lijkt me ijdele hoop, zeker omdat het kennelijk overheden zijn die deze mods aanbrengen en overheden hebben
meestal wel een root certificaat in het systeem zitten waarmee ze ieder gewenst signing certificaat kunnen uitgeven.

Ik denk niet dat ik eerder heb gezien dat iemand een bijdrage van Bitwiper samenvatte als "blaat".
In dit geval was Bitwiper's bijdrage blijkbaar voor https://www.security.nl/profile?alias=de+kat+zijn+ellebogen.

Tjonge, ik vind het toch wel zorgelijk dat zorgvuldige reacties zó afgeschilderd worden....wat een armoe van geest....

Het risico nemen, je kennis vergroten of stoppen met downloaden.

Ik heb al jaaaaren geen virussen meer gezien, zelfs niet voor Windows.

Sure. Momenteel de helft van de pagina van https://www.heise.de/security/:
- Samba
- Joomla + LDAP
- Wordpress
- Magento
- Malware in Python's officiële repository
- Apache "optionsbleed"

Zowel open als closed source is lek of bevat bewust ingebouwde backdoors. Onder meer doordat programmeurs, zowel open als closed source, hun code bij elkaar Googelen en hersenloos stommiteiten en/of minimalistische democode plakken (zie https://www.heise.de/security/meldung/Studie-Android-Entwickler-kopieren-oft-auch-Sicherheitsluecken-3837076.html of de Engelstalige bronnen onderaan die pagina), of doordat ze hun (online) repository onvoldoende beveiligen (zie bijv. http://chrispederick.com/blog/web-developer-for-chrome-compromised/).

Gelukkig heb ik een dikke huid :-)

Kan je dat niet met de ingebouwde developer tools van je browser zien?
Of anders met Firebug. (addon voor Firefox browser)

1.Installeer FireBug
2.Open firebug
3. ga naar de "net" tab
4. Klik op "persist" optie
5. vul daar de url in die je wilt bezoeken.
Let vervolgens op de veranderende URL-lijst waar je een entry met "http 307 redirect" of iets dergelijks langs ziet komen.

https://superuser.com/questions/242138/how-to-track-url-redirects-in-the-browser

Ennnnn... dan hebben we nog in Firefox in about:config
die je op "true" zou kunnen zetten.

Dan wordt je voor elke soort tijdelijke redirect gewaarschuwd waaronder http 307.
Houd er wel rekening mee dat de meeste redirects niet kwaadaardig zijn, maar je wordt dus wel even getriggerd.

Slik.... *b..blaat*...?!

Ik ben vandaag hier nu pas aan het lezen en moet kwijt dat ik niet eerder zo'n - zijdezacht uitgedrukt - misplaatste reactie heb gelezen. Treurig!

@anoniem, als Security.nl een Razzie-Award zou gaan toekennen ben je m.i. een reuze kanidaat om deze als eerste met onbetwijfelbaar veel genoegen uit handen van de redactie te ontvangen.
Hevig nadeel: Je zult dan wel plaats moeten maken in je prijzenkast tussen al de andere eikel & knuppel hoofdprijzen die je ongewijfeld door bijdragen elders al in ontvangst hebt mogen nemen.

Een digitale handtekening vereist wederom een encryptie programma zoals Gpg4win, of PGP, om de handtekening te verifiëren, en daarbij moet de gebruiker ook nog eens de publieke sleutel zelf als betrouwbaar signeren.
De Hash geplaatst op de website waar ook de software vanaf wordt gedownload is daarom veel eenvoudiger en net zo betrouwbaar. Maar ook hiervoor moet men een Hash calculator op de computer hebben geinstalleert.
Persoonlijk gebruik ik HashCalc van SlavaSoft.
In Principe de zwakste schakel in de keten, omdat ik deze alleen met mij virusscanner kan controleren.

Ik ben nog niet over op versie 2.2.x van GnuPG, maar dit werkt in 1.4.x:

Met 'gpg --version' kan je een overzicht krijgen van alle ondersteunde hash algoritmes.

Voorbeeld:

Je kan de hashes ook opzoeken in www.virustotal.com , je moet alleen even de spaties verwijderen (maar volgens mij kan dit ook met een toetsencombinatie, die ik helaas vergeten ben).

Tegenwoordig kunnen we daar een blockchain tegenaan gooien.

http://opensig.net/

Begin met een risico analyse m.b.t. de vraag of jij denkt een doelwit te zijn van de overheid, en of er dus enige kans bestaat dat deze dreiging impact voor jou zal hebben. Is dit niet het geval, ga dan gewoon verder met je leven, en maak je niet zoveel zorgen. Tenzij je volstrekt paranoide bent natuurlijk.

Nee, want als je het goed aanpakt zijn er veel minder mensen die toegang hebben tot een private key dan tot een webserver (schrijfrechten).

Dat kan, ook onder Windows, met boordmiddelen:

Ik sta aan de kant van Bitwiper.

Zijn inzichten verdienen goede overdenking en versimpeling is geen oplossing in de strijd met de staats-pn*wn3rs.

Met een praatje pot ben je niet geholpen.

NSA voorop met het trachten zijn onveilige algoritmen aangenomen te krijgen en met het verzwakken van Dual EC DRBG etc. hadden het globale vertrouwen al grotendeels verspeeld.

Lees in dat verband nog eens dit: https://www.security.nl/posting/385374/NIST+verwijdert+verdacht+NSA-algoritme+van+advieslijst

Pseudo-random generatoren doen de rest.

Na het CCleaner-piriform/avast drama zie ik dat de staats C2 server ratten overuren maken.

De "andere kant" vertrouwt terecht de Anglo-Amerikaanse ondergraving op de infrastructuur niet meer en daarom moeten acties als van Group 72 etc. ons ook niet verbazen.

Een vinger precies erop leggen van wat er gebeurt, zal voor een eenvoudig sterveling al moeilijk genoeg zijn.

luntrus

Let op, niemands desktop is onkwetsbaar (ookal verlangen we daar allemaal naar):

https://www.security.nl/posting/461927/Backdoor+in+Linux+Mint-iso+maakt+mogelijk+50+slachtoffers.

Tegelijkertijd is het kleine aantal slachtoffers t.o.v. de ccleaner backdoor dan weer argument voor jouw stelling.

Tja, en de vraag of je besmet kan worden hangt enkel en alleen van het OS af ? Wat dacht je van configuratie, system hardening, applicaties die draaien boven op het OS, en ga zo maar door.


Kiezen voor open source is helemaal geen beveiligingsmaatregel. Indien je dit de beste oplossing noemt, dan weet je niet waar je het over hebt.

Alle ondersteunde hash algoritmes? Tails onder steunt maar liefst 30 verschillende hash algoritmes!
Maar eigenlijk heb je in de gegeven situatie al genoeg aan bestandsgrootte met twee hashes.
Om Finfisher erbij te proppen en de bestandsgrootte gelijk te houden is meestal al niet te doen.
En om daarbij ook nog twee of drie hashes gelijk te houden lijkt me schier onmogelijk.
Als de MD5 en SHA1-hash en de bestandsgrootte zijn wat het behoort te zijn, weet je eigenlijk wel dat het okee is.
En anders controleer je ook nog even met een derde hash als je het niet vertrouwt. Dat is echt wel genoeg.

Wel lastig wanneer je vrienden allemaal op Whatsapp zitten, en jij geen Whatsapp voor je Linux kan vinden....

Waarom denken mensen nog steeds dat er geen software voor linux is?
Ik kon het vinden in enkele seconden...
https://github.com/Enrico204/Whatsapp-Desktop

Verder heb je nog whatsapp plugin voor pidgin. Of je kan natuurlijk de webversie gebruiken:
https://web.whatsapp.com

Gelukkig maar. Je post bitwiper was en is prima.

Dat komt omdat het geen officiële versies zijn en webversie (https://web.whatsapp.com) noemt ook niks voor Linux.

Als de sleepnetwet doorgaat kan onze Nederlandse overheid dezelfde truuk toepassen.
De geplande sleepnetwet houdt immers ook in dat ze je mogen besmetten met spyware/malware.
Hashes en bestandsgrootte worden niet vermeld op de whatsapp downloadsite, dus er is niks te controleren.
Men geeft lang niet altijd een hash en bestandgrootte bij downloads aan.

https en certificaat helpen je niet.
Zodra je op download drukt, kan je overal heen worden geleidt zonder dat je browser ook maar een kick geeft.
Een Man-In-The-Middle bij de ISP kan deze https downloadaanvraag van verdachten automatisch omleiden,
maar met opzet de website zelf niet, zodat jij denkt dat je veilig bent en https en certificaat zelfs goed hebt gecheckt.
Zodra je echter de download start, is alle veiligheid verdwenen.
Omdat de download niet noodzakelijkerwijs van dezelfde website hoeft te worden gedownload.
De download kan zelfs via http gaan, ook al start je de download vanaf een https site.

Wil je als onschuldig burger (die toevallig door een misverstand bij de AIVD verdacht is) geen slachtoffer worden van zulke praktijken? Eventjes goed invullen en tekenen: http://teken.sleepnet.nl
(om tenminste nog een kans te hebben dat die wet niet doorgaat)

Je kunt altijd nog via de metadata controleren waar de download vandaan kwam. In elk geval bij de mac, die dit bij elke download vasthoud. Heel vroeger kon je dit ook in de finder info lezen. Nu moet je via het terminal commando "mdls" de metadata opvragen.
In de kMDItemWhereFroms variabele staat de hele download url plus protocol.

Voor geïnteresseerden: op de vraag of een ISP een "http redirect" kan injecteren in een https verbinding heb ik een lang antwoord geschreven in https://www.security.nl/posting/532047/ESET%3A+Providers+voorzien+downloads+van+overheidsspyware#posting532389.

Bedankt voor de uitleg Bitwiper, maar ik geloof dat je wat dingen vergeet hierbij.
Whatsapp is een https website, en slachtoffers kwamen uit bij de echte pagina van whatsapp volgens het door ESET gebruikte plaatje: https://www.welivesecurity.com/wp-content/uploads/2017/09/Figure2.png
Dat wil zeggen: ze zagen het juiste certificaat, want ze waren op de echte website. Groen licht dus,.
Maar pas toen ze op de downloadknop klikten, werden ze omgeleid met als resultaat een besmette Whatsapp versie.
Bekend is dat de ISP erbij zou zijn betrokken als MITM en m.b.v. redirect 307 de gebruiker naar de valse versie voerde.

Dit is toch niet meer uit te leggen met jouw theorie(?). Probeer dit (*in deze thread*) van jouw kant maar eens te verklaren, en denk eens Out-of-the-Box wat er technisch "in theorie" allemaal mogelijk is en ook met niet al teveel moeite in de praktijk zou kunnen worden gebracht.

Ik concludeer: als dit m.b.v. een ISP kan, dan kan bijv. onze overheid met een dwangbevel aan een ISP ook mensen infecteren met valse software, en zelfs nog makkelijker met de aanstaande aftapwet(sleepnet) die hacken toestaat en "zero day" malware gebruiken toestaat. (zeroday wordt niet herkent door virusscanners)

In ieder geval lijkt het mij te kunnen in de normale situatie, dus zonder VPN's e.d. en je merkt er niets van.
Met die redirects kan ook gerommeld worden. De standaard schrijft wel voor dat ze de browser van een gebruiker
over de redirect moeten informeren, maar technisch is het natuurlijk te wijzigen dat dit niet gebeurt...
En dan kan je nergens aan zien dat je genept bent.
Heel tricky dit.

Ik denk het niet (vond je de bijdrage niet lang genoeg, of had je willen lezen dat ik -onterecht- zou toegeven dat het injecteren van http redirects in een https verbinding mogelijk is?).

Helaas laat dat plaatje niet zien of sprake is van http of https (tenzij ik erover heen kijk).

Sterker, als ze een up-to-date webbrowser gebruiken met ingebouwde HSTS preload lijst en in hun URL-balk "whatsapp.com" of zelfs "http://whatsapp.com/" hebben ingetikt, zal hun browser de verbinding meteen via https maken.

ECHTER: dat gebeurt niet als ik "whatsapp.nl" intik in de URL balk van Firefox, want alleen whatsapp.com staat in de preload lijst!

Als antwoord krijg ik dan -via onversleutelde http- een http 301 "Moved permanently" naar "Location: http://www.whatsapp.com" (allemaal te zien met het "F12" developerscherm van Firefox). Van die laatste http maken moderne browsers https als gevolg van de HSTS preload lijst (voor Firefox zie https://hg.mozilla.org/mozilla-central/file/tip/security/manager/ssl/nsSTSPreloadList.inc).

Het is voor een foute ISP niet moeilijk om die redirect niet door te sturen naar de browser van de eindgebruiker, maar in plaats daarvan de content van whatsapp.com te laten zien (onder de door de gebruiker intgetikte http URL - zonder slotje dus). Dan kan de ISP de gebruiker laten zien wat zij wenst, en bestanden naar keuze toezenden zodra de gebruiker op "download" klikt. Gebruikers die niet weten dat zij een https URL zouden moeten zien, en die geen hulp krijgen van HSTS preload, zijn zo eenvoudig te foppen (dit is precies waarom een SSLstrip aanval zo succesvol kan zijn).

Als ik op de Download knop druk voor de windows versie, is de download URL https://web.whatsapp.com/desktop/windows/release/x64/WhatsAppSetup.exe. De FQDN van web.whatsapp.com is "mmx-ds.cdn.whatsapp.net" en het IP-adres voor mij is 31.13.91.51. Volgens whois is dat een adres geregistreerd bij RIPE, in Europa dus, maar een traceroute lijkt te suggereren dat pakketjes gerouteerd naar dit IP adres toch naar de USA gaan - maar dat hoeft niet in alle gevallen zo te zijn. Het is best mogelijk dat iemand in Kazakhstan voor deze domeinnaam een ander IP-adres terugkrijgt van een server gehost ergens bij een ISP in Kazakhstan. Maar het kan daarbij ook om hetzelfde IP-adres gaan: de ISP kan routeren hoe zij wenst. Voorwaarde is dat de (CDN) server over de private key beschikt, behorende bij de public key in het whatsapp certificaat.

Ook mijn download vond dus niet plaats vanaf https://www.whatsapp.com/, maar vanaf een andere server. Daarbij werd mijn browser niet omgeleid via een redirect (de donwload link zelf wees naar een andere server). Het betrof in mijn geval echter netjes een https link - waar een ISP niet tussen kan komen met een http redirect.

In Wireshark zag ik achter elkaar (alles naar poort 443, met TLSv1.2, van 31.13.91.51 dat ik hieronder "WA" noem om de regels niet te lang te maken):

Naast dat CDN servers overal kunnen staan (en voor meer mensen fysiek toegankelijk zijn dan je zou willen), sluit ik ook niet uit dat WhatsApp door bepaalde bepaalde landen gedwongen kan worden om downloads via http aan te bieden, en dan kan elke MitM zich natuurlijk uitleven.

Wat ik in mijn bijdrage https://www.security.nl/posting/532047/ESET%3A+Providers+voorzien+downloads+van+overheidsspyware#posting532389 probeerde uit te leggen is dat een ISP welliswaar geen "http redirect" kan injecteren in een https verbinding, maar je, onder meer via aangepaste routering, je met elke gewenste server kan laten verbinden. Alleen krijgt de gebruiker wel een certificaatfoutmelding als die server vervolgens niet over de juiste private key beschikt.

Bekend? Waar staat dat dan?

Op de manier waarop ik gedownload heb, is het (voor zover ik weet) onmogelijk om een http redirect te injecteren, want er is geen http verkeer zichtbaar geweest in Wireshark die ik open had tijdens download.

Nou goed dan. Naast bovengenoemd scenario (http website) kan de ISP ook de 80MB download elke keer tussendoor afbreken (bijv. alles meer dan 1MB vanaf 31.13.91.51). Na een paar keer zal een gebruiker dan in Google iets intikken als: "download whatsapp windows" en bijv. op deze pagina uitkomen: http://download.cnet.com/WhatsApp-for-PC/3000-2150_4-76640933.html. Grappig is dat in de knop "Download now", onder die tekst, "Secure download" staat (LOL).

Overigens vind ik het wel heel slecht van WhatsApp dat de signature van WhatsAppSetup.exe, die ik gedownload heb, (1) nog gebruik maakt van een SHA1 hash en (2) geen signed timestamp heeft (zie Signature Info in de Details tab in https://www.virustotal.com/#/file/b3a885d061f51f01ddc578163ace8f261a9fd679802e5c735413bdb1ae0872a9/details).

Als er op een HTTPS pagina een download knop staat die verwijst naar een download link met een andere domeinnaam
dan de pagina zelf (en dat lijkt zo te zijn volgens bovenstaande verhandeling) dan is het uiteraard mogelijk dat de ISP
de resolve van deze download domeinnaam beantwoordt met een ander IP adres dan wat WhatsApp in gedachte had.
Als dit in opdracht van een overheid gedaan wordt kan die uiteraard ook een certificaat bijleveren voor die domeinnaam
zodat dit geen beveiligings waarschuwingen geeft. Of zelf die downloadserver+certificaat maken en de ISP de opdracht
geven daar heen te wijzen met DNS.

Denk je dat overheids spyware niet te verbergen is in open source software ? En doe jij dagelijks een code review ? Ik vind het grappig hoe mensen denken dat het gebruik van open source plotseling alle risico's weg zou nemen. Verder gaat het hier over malware, in de infrastructuur van de ISP. De vraag of ze open source gebruiken, daar heb jij geen invloed op. En of ze open source gebruiker of niet, het planten van malware blijft mogelijk.

Ging dit gepaard met net daarvoor een DNS request om het IP-adres van mmx-ds.cdn.whatsapp.net te vinden?...

Ehm.... "mmx-ds.cdn.whatsapp.net" blijkt niet te beschikken over HSTS, en staat niet in de HSTS preload lijst.
De vraag is voor mij nog even of er van een ander IP-adres wordt gedownload dan het IP-adres van de whatsapp website?

Vanzelfsprekend. Maar als ik nu, vanaf een andere locatie, "nslookup mmx-ds.cdn.whatsapp.net" uitvoer, krijg ik 31.13.72.52 terug als IP-adres. Dat dit wisselt is gebruikelijk bij potentieel zwaar belaste sites.

Jazeker. Als ik nu "nslookup www.whatsapp.com" doe, krijg ik als antwoord:
En als ik dezelfde nslookup herhaal, zijn die adressen gerouleerd (er staat een andere bovenaan, die zal worden gebruikt).

Om precies te zijn heeft de server achter het IP-adres waar mijn PC gisteren verbinding mee maakte (31.13.91.51) geen HSTS preload headers aangeboden, en staat "mmx-ds.cdn.whatsapp.net" niet in de HSTS preload lijst. Maar dat boeit allemaal niet, want de URL die mijn browser voor download gebruikte, luidde https://web.whatsapp.com/desktop/windows/release/x64/WhatsAppSetup.exe en "*.whatsapp.com" staat wel in de HSTS preload lijst.

Dat je vervolgens onder water via DNS op een bepaald IP-adres met andere CNAME (en whatever aliases) uitkomt, is irrelevant voor de browser (mits die server aantoont te beschikken over de private key behorende bij de public key in het certificaat voor *.whatsapp.com): de browser downloadt met laatstgenoemde URL - via https dus, en vanaf web.whatsapp.com.

Zoals ik al eerder schreef: met https ben je totaal onafhankelijk van MitM's op de lijn maar ook ben je (bugs daargelaten) ook ongevoelig voor ARP-, DNS - en BGP attacks (tenzij er sprake is van een DV certificaat en tijdens de aanvraag zo'n aanval plaatsvond). De enige voorwaarde is dat de server waar je verbinding mee maakt, beschikt over de private key horende bij de public key in het certificaat dat is uitgegeven voor de domainname in de gebruikte URL. En natuurlijk dat je certificaatwaarschuwingen serieus neemt...

Ik heb voor de zekerheid de proef op de som genomen met Firefox en Wireshark open: als ik als download-URL invoer http://web.whatsapp.com/desktop/windows/release/x64/WhatsAppSetup.exe (dus beginnend met http i.p.v. https), dan zal Firefox automatisch (zonder http communicatie) de URL in de https variant wijzigen en daarmee downloaden.

Voor degenen die denken dat ISP's in https verbindingen "http redirect" commando's zouden kunnen injecteren: dat zou dan elke MitM kunnen doen, en dat zou https geheel zinloos maken. Tenzij er sprake is van een ongepubliceerde bug kan dit echt niet.

Dat is te hopen, Bitwiper. Het is alleen dat het me in het verleden meerdere malen is overkomen dat ik op een https website op "download" klikte, maar dat die https website ervoor zorgde dat het bestand van een http-website werd gedownload.

Dat hangt er van af of de downloadsite echt beslist de key moet hebben van de oorspronkelijke https website waar je de download hebt gestart. Staat dit ergens officieel gedocumenteerd?[/quote]

De "FinFly ISP" was eerder al gelekt naar wikileaks.
https://wikileaks.org/spyfiles4/documents/FinFly-ISP-Catalog.pdf
https://wikileaks.org/spyfiles/files/0/297_GAMMA-201110-FinFly_ISP.pdf

Hierin vind je ook de FinFly ISP features:
» Can be installed on an Internet Service Provider ?s networks
» Handles all common protocols (dus niet alleen maar http?...)
» Targets selected systems by IP address (v4/v6), radius login name, DHCP or MSISDN
» Hides remote monitoring solution in downloads of targets
» Deploys a remote monitoring solution as a software update
» Remotely installs a remote monitoring solution through websites visited by the target

Het is al in een aantal landen ingezet, waaronder in Europa: Spanje(EU-land!), Slovenië en Bosnië.
Finfly is bedoeld als onopvallend staatssurveillance gereedschap, en is natuurlijk aantrekkelijk voor alle overheden in de wereld. En http://infosecuritymagazine.nl/2014/09/15/nederlandse-politie-gaf-27-miljoen-euro-uit-aan-finfisher-spyware/ Nog niet vergeten toch zeker? Jaja, de burger betaalt zijn eigen overheidssurveillance. Hoe ironisch.

Dat is (helaas) gebruikelijk; dat de 80MB download van WhatsApp voor Windows via https plaatsvindt is best uitzonderlijk.

Feit is dat de URL in de pagina dynamisch is, afhankelijk van wat jouw browser aan die site vertelt. Mij werd een 64bit versie aangeboden, terwijl als ik met Firefox op Android "WhatsApp for Windows" probeer te downloaden, ik in de Google Play store terecht kom. Niets belet WhatsApp om jou een http link te geven als jouw IP-adres of taalinstelling Russisch is.

Je hebt het niet goed begrepen. Elke https URL die je aanroept, moet een geldig certificaat naar jouw browser sturen voor de domeinnaam in die URL.

Voorbeeld: toen je deze security.nl pagina opende in jouw webbrowser, heeft "de server van security.nl" [*] het certificaat van security.nl naar jouw webbrowser gestuurd, en heeft vervolgens, op verzoek van jouw webbrowser, aangetoond over de private key te beschikken die hoort bij de public key in het certificaat van security.nl.

In deze security.nl pagina kan een link staan naar een te downloaden file, zoals https://wikileaks.org/spyfiles4/documents/FinFly-ISP-Catalog.pdf. Op het moment dat je op die link klikt, is sprake van een totaal afzonderlijke sessie met een geheel andere server. De wikileaks.org server zal haar certificaat naar jouw browser sturen, waarna jouw browser aan die server zal vragen te bewijzen over de private key te beschikken, behorende bij de public key in het wikileaks.org certificaat.

Interessant wordt het als een server downloads van een file zowel via https als http ondersteunt, zoals bijv. Didier Stevens doet met zijn tools (info over deze tool in https://blog.didierstevens.com/programs/authenticode-tools/):
1) https://didierstevens.com/files/software/AnalyzePESig_V0_0_0_5.zip
2) http://didierstevens.com/files/software/AnalyzePESig_V0_0_0_5.zip

Als je op de eerste link klikt, zal de server van Didier, of een evt. MitM aanvaller, jouw browser een geldig certificaat voor didierstevens.com moeten sturen, en moeten aantonen over de bijbehorende private key te beschikken; zo niet volgt een certificaatwaarschuwing.

Als je op de tweede link klikt, kan een MitM jou via meerdere soorten aanvallen een ander bestand toezenden.

[*] Jouw browser communiceert nu direct met een server van security.nl, maar eerder is dat een tijd met een server van CloudFlare, een CDN provider geweest. Om dat mogelijk te maken had Cloudflare servers bij meerdere ISP's, met op elk (naast het certificaat van security.nl) ook de bijbehorende private key.

Ik hoop dat het hiermee duidelijk is voor je.

@Bitwiper 23:14
Hee, dan was je het eigenlijk oorspronkelijk met me eens. ; )
Maar die oplossing loopt dus stuk.

Neem nu de download van Teamviewer, https://www.teamviewer.com/nl/download/windows/
Certificaat fingerprint SHA256:A6:12:34:CF:97:20:1E:EF:A2:10:99:7C:5E:03:07:EA:00:AF:43:6A:06:29:52:E1:B8:1F:06:93:D0:34:8A:BA

Druk je op download, dan wordt je omgeleid naar
https://download.teamviewer.com/download/TeamViewer_Setup.exe (IP 46.163.100.213)
met fingerprint SHA256: 442da86882077ced9ea9089c87e406ccdc83a26c6b7fe0cce6ca493b30a8b06e
Dat is een tussenstap waar je na klikken op download automatisch langs gaat en waarvan geen certificaat wordt getoond.
Het domein (teamviewer.com) is wel hetzelfde en dat stelt enigzins gerust, maar dan heb je het ook wel gehad.
De certificaatgegevens kon ik nog wel op andere manier verkrijgen, maar is natuurlijk omslacht.

En tenslotte gaat het met een redirect naar
https://dl.tvcdn.de/download/TeamViewer_Setup.exe
waar het bestand dan eindelijk wordt gedownload, en met certificaat fingerprint SHA256:C3:7F:65:1C:76:E8:95:2F:54:08:EB:6F:C5:CE:9C:0C:E7:B1:7C:0C:18:12:F2:13:85:FD:CB:BA:75:AF:08:F5

Drie verschillende fingerpints, dus drie verschillende certificaten.
En dl.tvcdn.de is bovendien een heel ander domein met echt een volstrekt ander certificaat.

Het probleem is dat ik op het eind alleen een kleine window zie oppoppen, die vraagt of ik wil downloaden of niet:

En daar wordt voor zover ik kan nagaan dus weer geen enkel certificaat van vermeld in je browser.
En al zou je een certificaat te zien krijgen, hoe ga je ooit weten of je daar wel heen moet.
Dát is het probleem.

Via Torbrowser (encrypted van jouw computer tot aan de laatste exitnode) van een https site (om encrypted verder te gaan) en met te een te controleren signatuur van het gedownloade softwarepakket.
Mooist is als die signatuur op meerdere plekken staat en niet alleen op de site waar de software te downloaden is.

Als het van eind tot eind encrypted verkeer is valt er weinig te injecteren in de software.
Controleeer je die software nog een keer dan zit je behoorlijk safe bij de garantie dat 100% veiligheid 'niet bestaat'.

Helaas is dat zo. Wat mij betreft is dit een browser bug, vergelijkbaar met bij een "basic authentication" dialoogbox waarbij je gebruikersnaam en wachtwoord moet invoeren voordat het slotje getoond wordt (laat staan dat je een certificaat zou kunnen checken).

In elk geval in Firefox kun je na een download de feitelijke download URL naar het klembord kopïeren en checken of het om een https URL (ipv http) ging. Ook kun je dan, zoals in bovenstaande situatie, https://dl.tvcdn.de/ openen en dan controleren aan welke organisatie het certificaat is verstrekt (indien vermeld, wat niet het geval is bij een DV certificaat). De domeinnaam "tvcdn" suggereert wel dat het om CDN server (s) van TeamViewer gaat - maar toen deze nog niet bestond kon iedereen die domeinnaam registreren.

Ongeacht jouw eventuele vertrouwen in tvcdn.de, is het wel een feit dat, als alle verbindingen t/m de uiteindelijke downloadlink, te beginnen op de TeamViewer webpagina, via https verlopen, het bedrijf TeamViewer kennelijk in alle betrokken servers vertrouwen stelt. Maar ook dat jij zeker weet dat je vanaf zo'n server (waar TV vertrouwen in stelt) hebt gedownload - zonder dat een MitM aanval mogelijk geweest kan zijn.

Als het om een beter-dan-DV-certificaat gaat, kun je in het certificaat zien aan welke organisatie dat is uitgegeven. Helaas zijn DV certificaten populair, helaas ook bij weinig zeggende domeinnamen.

Bijv. van cdn.teamviewer.com zou onmiskenbaar duidelijk zijn dat de DNS entry daarvoor van het bedrijf TeamViewer is - een DV certificaat betekent dan een kleiner risico (hoewel het voor een doortastende aanvaller niet onmogelijk is om daar een DV certificaat voor te bemachtigen).

Dat klopt normaalgesproken wel. (maar zo normaal (b)lijkt het niet altijd meer te gaan tegenwoordig,
en het gaat me natuurlijk niet zozeer om Teamviewer, dat is maar een voorbeeld om te tonen waar de schoen wringt.
Deze thread gaat oorspronkelijk over wat te doen bij ongemerkt netwerkverkeer omleiden bij ISPs en ook in het algemeen om te voorkomen dat we besmette downloads op onze computer binnenkrijgen)

Zoals je in de post van 01:39 wel kunt zien, heb ik voor het achterhalen van 2 fingerprints de browser gebruikt, en bij eentje lukte dat niet. (https://download.teamviewer.com/download/TeamViewer_Setup.exe).
Dus een alternatief gebruikt om de fingerprint te achterhalen. Want al zet je deze url nog eens apart in de browser,
hij gaat altijd direct automatisch door naar dl.tvcdn.de.
Zo kan het ook wel eens gebeuren dat een downloadwebsite niet tolereert dat je een domein vanuit de browser kunt benaderen. Er wordt dan bijvoorbeeld gelet op de referrer info of het verkeer wel vanaf een bepaalde server kwam.

Eigenlijk verwacht ik nog een gedetailleerdere technische uitleg van ESET, en ik ben benieuwd of de onveilige verify window er nog iets mee te maken heeft. Ideaal aanvalspunt voor een MITM ISP.