Security Professionals
- ipfw add deny all from eindgebruikers to any
Browsers/CSP's security++
TL,DR:
Stelling:
1) Webbrowsers moeten de mate van authenticiteit (hoe betrouwbaar het is dat een website van een geclaimde organisatie is) gaan tonen, en eventueel aanvullende gegevens in het Subject van het https servercertificaat kunnen tonen;
2) CSP's (Certificate Service Providers, certificaatuitgevers) moeten, naarmate zij betrouwbaarder identificerende digitale certificaten uitgeven, strenger worden gecontroleerd waarbij uitgifteregels streng gehandhaafd moeten worden.
Referentie: persoonsauthenticatie
Logius schrijft in [1] (ingekort en opmaak toegevoegd door mij):
Belangrijk:
Het gaat hierbij dus niet om de betrouwbaarheid van de inlogger, maar om hoe zeker de verifiërende partij weet dat de inlogger geen identiteitsfraudeur is.
Ter verduidelijking: officieel mag je niet inloggen met de DigiD van een ander, maar in de praktijk vraagt lang niet iedereen een machtiging aan om bijv. voor ouders de belastingaangifte te verzorgen.
Inloggen kun je sowieso in veel situaties vergelijken met het slot en bijpassende sleutels van jouw voordeur (of bijv. fiets): het bezit van een passende sleutel is géén bewijs dat jij jij bent. Het doel van een slot plus sleutels is het voorkómen dat niet door jou vertrouwde personen jou schade kunnen berokkenen. Een beter slot, en digitaal een sterker authenticatiemiddel zoals een langer, uniek en niet te raden wachtwoord, is in de eerste plaats bedoeld om te voorkómen dat niet door jou vertrouwde mensen daarmee "binnen kunnen komen".
Immers, beheerders (van een website waar je op inlogt) kunnen in principe ook jouw wachtwoord achterhalen, net als meegluurders zoals google-analytics en de makers van het door jou gebruikte besturingssysteem, de browser die je gebruikt om in te loggen (en plug-ins daarin), een eventuele wachtwoordmanager en mogelijk op jouw apparaat actieve malware.
Identiteit-verifiërende partij
In [2] heb ik uitgebreid uitgelegd waarom het noodzakelijk is dat, als je ergens authenticeert, je de verifiërende partij zult moeten vertrouwen - o.a. omdat je niet wilt dat die verifiërende partij zich, als AitM (Attacker in the Middle), voordoet als jou richting een andere partij.
Óf een verifiërende partij betrouwbaar is, weet je nooit voor 100% zeker - net zoals de verifiërende partij niet weet hoe betrouwbaar de inlogger is. Het beste dat techniek (een certificaat) plus een TTP (Trusted Third Party), de CSP, jou kunnen bieden is het beschikbaar maken van voldoende authenticerende gegevens om de kans op verwisseling met identiteitsfraudeurs te verkleinen, naast informatie die aangeeft hoe betrouwbaar die gegevens zijn (hoe streng zijn de controles geweest / hoe eenvoudig zijn die te omzeilen).
Eén van de redenen dat ik fel tegenstander ben van digitale absolute authenticatie (inloggen middels een "digitaal paspoort" met sterk identificerende persoonsgegevens) op willekeurige websites, is dat we er de laatste jaren geen idee meer van hebben of een website, gegeven een domeinnaam, daadwerkelijk van de geclaimde organisatie is.
Belang van authenticiteit ook als je niet inlogt
Afgelopen week beschreef het BlackBerry Research & Intelligence Team ([3], bron: [4]) een phishingaanval op (verwachte) bezoekers van de nu lopende NAVO-top in Litouwen. Onderdeel van die phishingcampagne was een nepwebsite.
Echt: https://ukrainianworldcongress.org/
Fake: https://ukrainianworldcongress[.]info/
Beide sites zijn momenteel live en lijken als twee druppels water op elkaar (vergelijkend plaatje: [5]). De nepsite lijkt uit slechts één pagina te bestaan; de paar links in die pagina die ik bekeken heb lijken allemaal naar subpagina's op de echte (.org) site te wijzen (het zou kunnen dat de domeinnaam van de nepsite ondertussen eigendom is van de eigenaren van de echte site, maar dan zou ik verwachten dat de fake site meteen doorstuurt naar de echte site).
De echte site heeft een Cloudflare DV (Domain Validated) certificaat, de neppe een DV cert van Let's Encrypt. Voor de echte site zijn al certs uitgegeven sinds 2018 [6], voor de nepsite pas sinds 26e juni van dit jaar [7].
Mijn punt: zonder een betrouwbare TTP is het voor de meeste bezoekers onmogelijk om te zien dat https://ukrainianworldcongress[.]info/ nep is (tenzij die mensen ooit https://ukrainianworldcongress.org/) hebben bezocht en die exacte domeinnaam - inclusief TLD - hebben onthouden én daar bij een bezoek op letten).
Problemen
Terwijl we steeds afhankelijker worden (gemaakt) van het web, neemt cybercrime (vooral phishing om "binnen te komen") toe en zijn we tegelijkertijd in een neerwaartse spiraal van de betrouwbaarheid van het web terechtgekomen.
De groene adresbalk bij een EV- (Extended Validation) certificaat is afgeschaft nadat onderzoekers aantoonden dat onbetrouwbare CSP's bestaan en dat de getoonde bedrijfsnaam plus vestigingsland niet altijd uniek zijn.
En in steeds minder webbrowsers (vooral op mobiele apparaten) kunnen verstandige en/of kwetsbare gebruikers https servercertificaten überhaupt nog inspecteren. Bovendien bevatten certificaten veel ingewikkelde gegevens die oninteressant zijn voor eindgebruikers (de browser controleert de correctheid van veel gegevens in een certificaat; het is zinloos om dat, handmatig, nog eens over te doen).
Juist doordat gebruikers in een deel van de gevallen geen verschil meer (kunnen) zien tussen verschillende soorten certificaten, gaan steeds meer websites over op DV-certificaten.
Zo schrijft Logius in [8]:
De belangrijkste reden om geen self-signed certificaten te gebruiken, is dat webbrowsers daar met idioot veel afschrikwekkende schermen (vergeleken met DV-certs, die vooral extreem populair zijn bij cybercriminelen) voor waarschuwen en zelden toestaan dat je deze met TOFU (Trust On First Use) op kunt slaan in jouw browser om toekomstige waarschuwingen te voorkómen.
Waar deze betweterigheid van browsermakers vandaan komt, is me overigens een raadsel - wat is er in hemelsnaam veiliger aan elke keer certificaatwaarschuwingen negeren om op mijn lokale netwerkapparaten in te kunnen loggen? (Sta opslaan in elk geval toe voor lokale apparatuur met RFC1918 IP-adressen).
Bovendien, hoewel gangbare browsers het niet zullen ondersteunen, beschrijft de RFC voor TLS v1.2 [9] zelfs dat TLS mogelijk is zonder https servercertificaat, nl. gebruikmakend van de DH_Anon modus of van een PSK (Pre-shared Key, een soort wachtwoord). Het is dus sowieso een mythe dat je een servercertificaat nodig heb voor een versleutelde verbinding; bijvoorbeeld SSH en WiFi kunnen ook zonder.
Logius gaat verder met:
Ook het NCSC vergeet in de PDF, die je in [10] kunt downloaden, dat een https servercertificaat uitsluitend bedoeld is voor authenticatie van de server: immers, de browser checkt of de in de adresbalk getoonde domeinnaam als geldig is opgenomen in het certificaat (naast dat die browser onder meer verifieert dat de server over de private key beschikt passend bij de public key in dat certificaat).
Dus ja, een bezoeker van https://ukrainianworldcongress[.]info/ weet redelijk zeker dat diens browser een versleutelde verbinding heeft met een server met die domeinnaam, maar heeft geen idee van wie de server, de website en de getoonde inhoud (waaronder potentieel malware-bevattende bestanden [11]) zijn. Zoals ik zo vaak zeg/schrijf: aan een "beveiligde verbinding" met een server van een crimineel heb je niks.
Nb. Microsoft heeft dinsdagavond bekend gemaakt ([12], bron [13]) dat bij deze aanval gebruik is gemaakt van zero-day exploit(s).
Een kanttekening die ik hierbij moet maken is dat DigiD ook een TTP is, waar niet elke flutwebsite aan kan koppelen (de server en website zullen aan bepaalde beveiligingseisen moeten voldoen).
Maar als je straks met jouw EDIW (European Digital Identity Wallet) direct op een website "aanmeldt", ben je volkomen afhankelijk van de betrouwbaarheid van de eigenaar van die website.
Zoals ik hierboven al schreef: betrouwbaarheid van een website (en/of beheerders daarvan) kun je nooit voorspellen en dus kan techniek je hier niet bij helpen. Wat wél kan, en m.i. moet, is dat bezoekers van een website in hun browser zien óf er meer identificerende gegevens (dan de domeinnaam/namen) in het https servercertificaat zijn opgenomen, en met welke betrouwbaarheid de CSP die heeft vastgesteld.
Browsers/CSP's security++
Om zichzelf beter te onderscheiden van nepwebsites, moeten te vertrouwen websites op betrouwbare wijze duidelijk maken wie de eigenaar van die site en content is.
Op z'n minst moeten browsers daarvoor een authenticatie-betrouwbaarheidsniveau (vergelijkbaar met de niveaus van DigiD) tonen.
Naarmate een CSP, naast controleren op het bezit van een domeinnaam, niet t/m grondig controleert dat een certificaataanvrager geautoriseerd is om een certificaat aan te vragen namens de organisatie waarvan aanvullende identificerende gegevens in het certificaat worden opgenomen, neemt de betrouwbaarheid (mate van authenticiteit) van een certificaat toe.
CSP's zullen strenger gecontroleerd moeten worden, waarbij handhavend moet worden opgetreden; zelfregulering door browsermakers en/of het CAB-forum volstaat niet (meer).
Hoewel organisaties niet van kosten, authenticeren en wachten op een certificaat houden, hebben cybercriminelen daar een nog véél grotere hekel aan. Hoe betrouwbaarder een certificaat, hoe minder cybercriminelen daar gebruik van zullen maken.
Daarnaast zouden browsers, eventueel op verzoek, de in het Subject van het certificaat opgenomen gegevens moeten (kunnen) tonen (dus niet alle gegevens in een certificaat - waarondee veel te veel voor eindgebruikers irrelevante details).
Conclusie
Als een (potentiële nep-) website een DV certificaat gebruikt, zou dat voor niet al te naïeve gebruikers een aanwijzing moeten zijn dat zij geen informatie en/of bestanden op die site kunnen vertrouwen, en er ook niet op in moeten loggen (dat laatste kan wel indien bijv. een wachtwoordmanager of "passkeymanager" uitsluitend inloggegevens prijsgeeft als de domeinnaam hetzelfde is als op het moment dat het account werd aangemaakt - maar dan wil je, vóór het aanmaken van dat account, zeker weten dat je op de juiste website "zit").
Een belangrijke voorwaarde daarvoor is dat echte, noodzakelijkerwijs te vertrouwen, websites (inclusief websites met een groot risico op spoofing, zoals het geval is bij https://ukrainianworldcongress.org/) betrouwbare https servercertificaten gaan gebruiken, en dat browsers duidelijk zichtbaar onderscheid maken tussen soorten certificaten - en identificerende gegevens van de organisatie, die zijn opgenomen in het certificaat, zichtbaar (kunnen) maken.
Nb. vooral bij targeted attacks zullen criminelen of statelijke actoren betrouwbare certificaten proberen te bemachtigen voor hun nepsites, maar we kunnen (en moeten) processen inrichten die dit zo moeilijk mogelijk maken.
Referenties
[1] https://www.logius.nl/domeinen/toegang/digid/documentatie/functionele-beschrijving-digid#index-11
[2] https://www.security.nl/posting/792391/Authenticatie+en+impersonatie
[3] https://blogs.blackberry.com/en/2023/07/romcom-targets-ukraine-nato-membership-talks-at-nato-summit
[4] https://www.bleepingcomputer.com/news/security/romcom-hackers-target-nato-summit-attendees-in-phishing-attacks/
[5] (download) https://blogs.blackberry.com/content/dam/blogs-blackberry-com/images/blogs/2023/07/romcom2-fig03.png
[6] https://crt.sh/?q=ukrainianworldcongress.org
[7] https://crt.sh/?q=ukrainianworldcongress.info
[8] https://www.logius.nl/domeinen/toegang/digid/documentatie/factsheet-dv-en-ov-certificaten-bij-digid
[9] https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2
[10] https://www.ncsc.nl/documenten/factsheets/2021/september/29/factsheet-pkioverheid-stopt-met-webcertificaten
[11] https://twitter.com/ClearskySec/status/1676141016858992641
[12] https://aka.ms/Storm-0978
[13] https://www.bleepingcomputer.com/news/security/microsoft-unpatched-office-zero-day-exploited-in-nato-summit-attacks/
Stelling:
1) Webbrowsers moeten de mate van authenticiteit (hoe betrouwbaar het is dat een website van een geclaimde organisatie is) gaan tonen, en eventueel aanvullende gegevens in het Subject van het https servercertificaat kunnen tonen;
2) CSP's (Certificate Service Providers, certificaatuitgevers) moeten, naarmate zij betrouwbaarder identificerende digitale certificaten uitgeven, strenger worden gecontroleerd waarbij uitgifteregels streng gehandhaafd moeten worden.
Referentie: persoonsauthenticatie
Logius schrijft in [1] (ingekort en opmaak toegevoegd door mij):
DigiD kent vier betrouwbaarheidsniveaus die de mate van zekerheid bepalen over de identiteit van de zich authentiserende [sic] gebruiker:
• DigiD Basis: [...]
• DigiD Midden: [...]
• DigiD Substantieel: [...]
• DigiD Hoog: [...]
• DigiD Basis: [...]
• DigiD Midden: [...]
• DigiD Substantieel: [...]
• DigiD Hoog: [...]
Belangrijk:
Het gaat hierbij dus niet om de betrouwbaarheid van de inlogger, maar om hoe zeker de verifiërende partij weet dat de inlogger geen identiteitsfraudeur is.
Ter verduidelijking: officieel mag je niet inloggen met de DigiD van een ander, maar in de praktijk vraagt lang niet iedereen een machtiging aan om bijv. voor ouders de belastingaangifte te verzorgen.
Inloggen kun je sowieso in veel situaties vergelijken met het slot en bijpassende sleutels van jouw voordeur (of bijv. fiets): het bezit van een passende sleutel is géén bewijs dat jij jij bent. Het doel van een slot plus sleutels is het voorkómen dat niet door jou vertrouwde personen jou schade kunnen berokkenen. Een beter slot, en digitaal een sterker authenticatiemiddel zoals een langer, uniek en niet te raden wachtwoord, is in de eerste plaats bedoeld om te voorkómen dat niet door jou vertrouwde mensen daarmee "binnen kunnen komen".
Immers, beheerders (van een website waar je op inlogt) kunnen in principe ook jouw wachtwoord achterhalen, net als meegluurders zoals google-analytics en de makers van het door jou gebruikte besturingssysteem, de browser die je gebruikt om in te loggen (en plug-ins daarin), een eventuele wachtwoordmanager en mogelijk op jouw apparaat actieve malware.
Identiteit-verifiërende partij
In [2] heb ik uitgebreid uitgelegd waarom het noodzakelijk is dat, als je ergens authenticeert, je de verifiërende partij zult moeten vertrouwen - o.a. omdat je niet wilt dat die verifiërende partij zich, als AitM (Attacker in the Middle), voordoet als jou richting een andere partij.
Óf een verifiërende partij betrouwbaar is, weet je nooit voor 100% zeker - net zoals de verifiërende partij niet weet hoe betrouwbaar de inlogger is. Het beste dat techniek (een certificaat) plus een TTP (Trusted Third Party), de CSP, jou kunnen bieden is het beschikbaar maken van voldoende authenticerende gegevens om de kans op verwisseling met identiteitsfraudeurs te verkleinen, naast informatie die aangeeft hoe betrouwbaar die gegevens zijn (hoe streng zijn de controles geweest / hoe eenvoudig zijn die te omzeilen).
Eén van de redenen dat ik fel tegenstander ben van digitale absolute authenticatie (inloggen middels een "digitaal paspoort" met sterk identificerende persoonsgegevens) op willekeurige websites, is dat we er de laatste jaren geen idee meer van hebben of een website, gegeven een domeinnaam, daadwerkelijk van de geclaimde organisatie is.
Belang van authenticiteit ook als je niet inlogt
Afgelopen week beschreef het BlackBerry Research & Intelligence Team ([3], bron: [4]) een phishingaanval op (verwachte) bezoekers van de nu lopende NAVO-top in Litouwen. Onderdeel van die phishingcampagne was een nepwebsite.
Echt: https://ukrainianworldcongress.org/
Fake: https://ukrainianworldcongress[.]info/
Beide sites zijn momenteel live en lijken als twee druppels water op elkaar (vergelijkend plaatje: [5]). De nepsite lijkt uit slechts één pagina te bestaan; de paar links in die pagina die ik bekeken heb lijken allemaal naar subpagina's op de echte (.org) site te wijzen (het zou kunnen dat de domeinnaam van de nepsite ondertussen eigendom is van de eigenaren van de echte site, maar dan zou ik verwachten dat de fake site meteen doorstuurt naar de echte site).
De echte site heeft een Cloudflare DV (Domain Validated) certificaat, de neppe een DV cert van Let's Encrypt. Voor de echte site zijn al certs uitgegeven sinds 2018 [6], voor de nepsite pas sinds 26e juni van dit jaar [7].
Mijn punt: zonder een betrouwbare TTP is het voor de meeste bezoekers onmogelijk om te zien dat https://ukrainianworldcongress[.]info/ nep is (tenzij die mensen ooit https://ukrainianworldcongress.org/) hebben bezocht en die exacte domeinnaam - inclusief TLD - hebben onthouden én daar bij een bezoek op letten).
Problemen
Terwijl we steeds afhankelijker worden (gemaakt) van het web, neemt cybercrime (vooral phishing om "binnen te komen") toe en zijn we tegelijkertijd in een neerwaartse spiraal van de betrouwbaarheid van het web terechtgekomen.
De groene adresbalk bij een EV- (Extended Validation) certificaat is afgeschaft nadat onderzoekers aantoonden dat onbetrouwbare CSP's bestaan en dat de getoonde bedrijfsnaam plus vestigingsland niet altijd uniek zijn.
En in steeds minder webbrowsers (vooral op mobiele apparaten) kunnen verstandige en/of kwetsbare gebruikers https servercertificaten überhaupt nog inspecteren. Bovendien bevatten certificaten veel ingewikkelde gegevens die oninteressant zijn voor eindgebruikers (de browser controleert de correctheid van veel gegevens in een certificaat; het is zinloos om dat, handmatig, nog eens over te doen).
Juist doordat gebruikers in een deel van de gevallen geen verschil meer (kunnen) zien tussen verschillende soorten certificaten, gaan steeds meer websites over op DV-certificaten.
Zo schrijft Logius in [8]:
De beveiliging van het TLS-verkeer tussen de webbrowser en webserver is voor de meeste toepassingen voldoende met een DV-certificaat.
Dat klopt. Sterker, dit geldt ook voor self-signed certificaten - die bijna net zo betrouwbaar zijn als DV-certificaten (die ook niet veiliger zijn dan DNS en BGP).De belangrijkste reden om geen self-signed certificaten te gebruiken, is dat webbrowsers daar met idioot veel afschrikwekkende schermen (vergeleken met DV-certs, die vooral extreem populair zijn bij cybercriminelen) voor waarschuwen en zelden toestaan dat je deze met TOFU (Trust On First Use) op kunt slaan in jouw browser om toekomstige waarschuwingen te voorkómen.
Waar deze betweterigheid van browsermakers vandaan komt, is me overigens een raadsel - wat is er in hemelsnaam veiliger aan elke keer certificaatwaarschuwingen negeren om op mijn lokale netwerkapparaten in te kunnen loggen? (Sta opslaan in elk geval toe voor lokale apparatuur met RFC1918 IP-adressen).
Bovendien, hoewel gangbare browsers het niet zullen ondersteunen, beschrijft de RFC voor TLS v1.2 [9] zelfs dat TLS mogelijk is zonder https servercertificaat, nl. gebruikmakend van de DH_Anon modus of van een PSK (Pre-shared Key, een soort wachtwoord). Het is dus sowieso een mythe dat je een servercertificaat nodig heb voor een versleutelde verbinding; bijvoorbeeld SSH en WiFi kunnen ook zonder.
Logius gaat verder met:
De meerwaarde van het publieke vertrouwen in een OV-, EV- of QWAC-certificaat is daarmee beperkt en meestal niet nodig voor toepassingen waar een lager niveau ook geaccepteerd wordt.
Dat is echt onzin.Ook het NCSC vergeet in de PDF, die je in [10] kunt downloaden, dat een https servercertificaat uitsluitend bedoeld is voor authenticatie van de server: immers, de browser checkt of de in de adresbalk getoonde domeinnaam als geldig is opgenomen in het certificaat (naast dat die browser onder meer verifieert dat de server over de private key beschikt passend bij de public key in dat certificaat).
Dus ja, een bezoeker van https://ukrainianworldcongress[.]info/ weet redelijk zeker dat diens browser een versleutelde verbinding heeft met een server met die domeinnaam, maar heeft geen idee van wie de server, de website en de getoonde inhoud (waaronder potentieel malware-bevattende bestanden [11]) zijn. Zoals ik zo vaak zeg/schrijf: aan een "beveiligde verbinding" met een server van een crimineel heb je niks.
Nb. Microsoft heeft dinsdagavond bekend gemaakt ([12], bron [13]) dat bij deze aanval gebruik is gemaakt van zero-day exploit(s).
Een kanttekening die ik hierbij moet maken is dat DigiD ook een TTP is, waar niet elke flutwebsite aan kan koppelen (de server en website zullen aan bepaalde beveiligingseisen moeten voldoen).
Maar als je straks met jouw EDIW (European Digital Identity Wallet) direct op een website "aanmeldt", ben je volkomen afhankelijk van de betrouwbaarheid van de eigenaar van die website.
Zoals ik hierboven al schreef: betrouwbaarheid van een website (en/of beheerders daarvan) kun je nooit voorspellen en dus kan techniek je hier niet bij helpen. Wat wél kan, en m.i. moet, is dat bezoekers van een website in hun browser zien óf er meer identificerende gegevens (dan de domeinnaam/namen) in het https servercertificaat zijn opgenomen, en met welke betrouwbaarheid de CSP die heeft vastgesteld.
Browsers/CSP's security++
Om zichzelf beter te onderscheiden van nepwebsites, moeten te vertrouwen websites op betrouwbare wijze duidelijk maken wie de eigenaar van die site en content is.
Op z'n minst moeten browsers daarvoor een authenticatie-betrouwbaarheidsniveau (vergelijkbaar met de niveaus van DigiD) tonen.
Naarmate een CSP, naast controleren op het bezit van een domeinnaam, niet t/m grondig controleert dat een certificaataanvrager geautoriseerd is om een certificaat aan te vragen namens de organisatie waarvan aanvullende identificerende gegevens in het certificaat worden opgenomen, neemt de betrouwbaarheid (mate van authenticiteit) van een certificaat toe.
CSP's zullen strenger gecontroleerd moeten worden, waarbij handhavend moet worden opgetreden; zelfregulering door browsermakers en/of het CAB-forum volstaat niet (meer).
Hoewel organisaties niet van kosten, authenticeren en wachten op een certificaat houden, hebben cybercriminelen daar een nog véél grotere hekel aan. Hoe betrouwbaarder een certificaat, hoe minder cybercriminelen daar gebruik van zullen maken.
Daarnaast zouden browsers, eventueel op verzoek, de in het Subject van het certificaat opgenomen gegevens moeten (kunnen) tonen (dus niet alle gegevens in een certificaat - waarondee veel te veel voor eindgebruikers irrelevante details).
Conclusie
Als een (potentiële nep-) website een DV certificaat gebruikt, zou dat voor niet al te naïeve gebruikers een aanwijzing moeten zijn dat zij geen informatie en/of bestanden op die site kunnen vertrouwen, en er ook niet op in moeten loggen (dat laatste kan wel indien bijv. een wachtwoordmanager of "passkeymanager" uitsluitend inloggegevens prijsgeeft als de domeinnaam hetzelfde is als op het moment dat het account werd aangemaakt - maar dan wil je, vóór het aanmaken van dat account, zeker weten dat je op de juiste website "zit").
Een belangrijke voorwaarde daarvoor is dat echte, noodzakelijkerwijs te vertrouwen, websites (inclusief websites met een groot risico op spoofing, zoals het geval is bij https://ukrainianworldcongress.org/) betrouwbare https servercertificaten gaan gebruiken, en dat browsers duidelijk zichtbaar onderscheid maken tussen soorten certificaten - en identificerende gegevens van de organisatie, die zijn opgenomen in het certificaat, zichtbaar (kunnen) maken.
Nb. vooral bij targeted attacks zullen criminelen of statelijke actoren betrouwbare certificaten proberen te bemachtigen voor hun nepsites, maar we kunnen (en moeten) processen inrichten die dit zo moeilijk mogelijk maken.
Referenties
[1] https://www.logius.nl/domeinen/toegang/digid/documentatie/functionele-beschrijving-digid#index-11
[2] https://www.security.nl/posting/792391/Authenticatie+en+impersonatie
[3] https://blogs.blackberry.com/en/2023/07/romcom-targets-ukraine-nato-membership-talks-at-nato-summit
[4] https://www.bleepingcomputer.com/news/security/romcom-hackers-target-nato-summit-attendees-in-phishing-attacks/
[5] (download) https://blogs.blackberry.com/content/dam/blogs-blackberry-com/images/blogs/2023/07/romcom2-fig03.png
[6] https://crt.sh/?q=ukrainianworldcongress.org
[7] https://crt.sh/?q=ukrainianworldcongress.info
[8] https://www.logius.nl/domeinen/toegang/digid/documentatie/factsheet-dv-en-ov-certificaten-bij-digid
[9] https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2
[10] https://www.ncsc.nl/documenten/factsheets/2021/september/29/factsheet-pkioverheid-stopt-met-webcertificaten
[11] https://twitter.com/ClearskySec/status/1676141016858992641
[12] https://aka.ms/Storm-0978
[13] https://www.bleepingcomputer.com/news/security/microsoft-unpatched-office-zero-day-exploited-in-nato-summit-attacks/
Reacties (12)
Oplossingen voor dat soort problemen moet je zoeken in de richting van protocollen die een login niet doen door de
usernaam en het password in een formulier naar de site te sturen, maar die een challenge/response protocol gebruiken
tussen de browser en de site, waarbij de gebruiker lokaal een usernaam/password invult of uit een opslag haalt, maar
deze niet op zodanige wijze over de verbinding gaan dat de site (of hackers daarvan) daar iets mee kunnen.
De challenge moet uiteraard het domein bevatten en de lokale agent moet dat controleren. En het moet zo in elkaar
zitten dat je geen man-in-the-middle kunt spelen tussen de bezoeker en de echte site.
Dat is vast allemaal al bedacht en geimplementeerd. Nu nog de uitrol.
usernaam en het password in een formulier naar de site te sturen, maar die een challenge/response protocol gebruiken
tussen de browser en de site, waarbij de gebruiker lokaal een usernaam/password invult of uit een opslag haalt, maar
deze niet op zodanige wijze over de verbinding gaan dat de site (of hackers daarvan) daar iets mee kunnen.
De challenge moet uiteraard het domein bevatten en de lokale agent moet dat controleren. En het moet zo in elkaar
zitten dat je geen man-in-the-middle kunt spelen tussen de bezoeker en de echte site.
Dat is vast allemaal al bedacht en geimplementeerd. Nu nog de uitrol.
Weer een erg goed stuk Erik van Straaten
Het internet is nooit gebouwd met veiligheid als vereiste, alleen om functionaliteit. En daar staan we nu. De "patches" zijn goed bedoeld maar niet perfect. Als je hier mee om kunt gaan is dat geen enkel probleem. Echter, de meerderheid wil/kan het niet begrijpen en dat heeft hele kwalijke gevolgen. Ik denk dat er geen oplossing voor is die iedereen wil...
Het internet is nooit gebouwd met veiligheid als vereiste, alleen om functionaliteit. En daar staan we nu. De "patches" zijn goed bedoeld maar niet perfect. Als je hier mee om kunt gaan is dat geen enkel probleem. Echter, de meerderheid wil/kan het niet begrijpen en dat heeft hele kwalijke gevolgen. Ik denk dat er geen oplossing voor is die iedereen wil...
12-07-2023, 13:08 door
Erik van Straten
Door Anoniem @11:22: Oplossingen voor dat soort problemen moet je zoeken in de richting van protocollen die een login niet doen door de usernaam en het password in een formulier naar de site te sturen, maar die een challenge/response protocol gebruiken tussen de browser en de site, waarbij de gebruiker lokaal een usernaam/password invult of uit een opslag haalt, maar deze niet op zodanige wijze over de verbinding gaan dat de site (of hackers daarvan) daar iets mee kunnen. De challenge moet uiteraard het domein bevatten en de lokale agent moet dat controleren. En het moet zo in elkaar zitten dat je geen man-in-the-middle kunt spelen tussen de bezoeker en de echte site.
Dit is erg lastig veilig te krijgen.Het grootste probleem is sowieso niet dat een aanvaller jouw wachtwoord in handen krijgt, maar dat zij of hij éénmalig als jou kan inloggen. In Windows wordt gebruikt wat jij voorstelt, met als gevolg PtH (Pass the Hash) aanvallen.
Door Anoniem: Dat is vast allemaal al bedacht en geimplementeerd. Nu nog de uitrol.
Bij WebAuthn (FIDO2 hardware sleutels en Passkeys [14]) gebeurt zoiets: de client "logt alleen in" als de domeinnaam van de website "hetzelfde" is (in elk geval, kijkend van rechts naar links, voor een voldoende groot deel overeenkomt) als tijdens het aanmaken van het account. Maar Passkeys hebben nog kinderziektes (ik heb zowel bij Apple als bij "Android" m.i. serieuze bugreports uit staan, die ik nog niet ga disclosen).Maar, zoals ik al schreef, dat effect kun je ook bewerkstelligen met een wachtwoordmanager die een wachtwoord alleen vrijgeeft als de domeinnaam klopt (ik heb recentelijk nogal wat tijd besteed aan tests met enkele KeePass-compatible wachtwoordmanagers, ook op iOS en Android, die checken op domeinnaam).
Probleem: al deze login-gerelateerde maatregelen voorkomen niet de beschreven aanval (download van een document met daarin een zeroday-exploit plus malware) van een lijkt-op website, noch het onbedoeld aanmaken van een account op een nepsite en/of het delen van persoonsgegevens (of andere vertrouwelijke informatie) met zo'n Trojaans Paard - en ook niet je op het verkeerde been laten zetten met fake news of andere propaganda ([15]).
En "straks" ook niet als jij (een deel van) de gegevens op jouw identiteitsbewijs, vanuit jouw EDIW (of apps zoals IRMA/Yivi) deelt met een criminele website. Het web is veel te onveilig voor hoe we het nu gebruiken, laat staan voor de "innovaties" die sommigen nastreven en als "de heilige graal" verkopen (zonder de risico's te benoemen).
[14] https://www.security.nl/posting/798699/Passkeys+voor+leken
[15] https://security.nl/posting/770336
Dank aan Anoniem @12:20!
Door Erik van Straten:
Het grootste probleem is sowieso niet dat een aanvaller jouw wachtwoord in handen krijgt, maar dat zij of hij éénmalig als jou kan inloggen. In Windows wordt gebruikt wat jij voorstelt, met als gevolg PtH (Pass the Hash) aanvallen.
Als je challenge zoals ik schreef de domeinnaam bevat, dan is dat niet mogelijk. Jouw browser logt niet in bij de hacker site omdat de domeinnaam niet matched tussen challenge en site, en als hij de challenge stuurt met bij hem zelf passende domeinnaam dan is die uitwisseling niet geldig met de originele site.Het grootste probleem is sowieso niet dat een aanvaller jouw wachtwoord in handen krijgt, maar dat zij of hij éénmalig als jou kan inloggen. In Windows wordt gebruikt wat jij voorstelt, met als gevolg PtH (Pass the Hash) aanvallen.
Bij Windows zit dat anders omdat het daar niet om server logons maar om domain logons gaat, en servers een domain kunnen representeren. Dat speelt niet bij het web, of in ieder geval niet op het level waar hackers de boel kunnen overnemen.
(het systeem zou nog zo kunnen werken dat een logon bij server1.example.com ook valid is voor server2.example.com, maar niet dat iemand een server3.example.org kan opzetten die logons doet voor example.com)
Maar, zoals ik al schreef, dat effect kun je ook bewerkstelligen met een wachtwoordmanager die een wachtwoord alleen vrijgeeft als de domeinnaam klopt (ik heb recentelijk nogal wat tijd besteed aan tests met enkele KeePass-compatible wachtwoordmanagers, ook op iOS en Android, die checken op domeinnaam).
Helaas is het wel zo dat sitebouwers de neiging hebben om hun loginpagina (domein) steeds aan te passen waarna de wachtwoordmanager geen account meer kan vinden en je zelf weer moet zoeken in de wachtwoordenlijst en als dat maar vaak genoeg gebeurt gaan mensen daar ook weer fouten mee maken. Incompetentie van sitebouwers en communicatieafdelingen is altijd moeilijk te bestrijden.
En "straks" ook niet als jij (een deel van) de gegevens op jouw identiteitsbewijs, vanuit jouw EDIW (of apps zoals IRMA/Yivi) deelt met een criminele website. Het web is veel te onveilig voor hoe we het nu gebruiken, laat staan voor de "innovaties" die sommigen nastreven en als "de heilige graal" verkopen (zonder de risico's te benoemen).
Ik denk nog steeds dat een deugdelijk identificatie systeem moet en kan worden gebouwd wat bijvoorbeeld werkt met een NFC readout van je rijbewijs of ID kaart, en wat tegen een website vertelt dat jij degene bent die je claimt dat je bent, zonder dat die website of criminelen die daar op ingebroken hebben iets met die informatie kunnen op andere plekken.
(bijvoorbeeld je daar identificeren voor het aangaan van nieuwe verplichtingen of het benaderen van persoonlijke data)
De informatie moet gelogd kunnen worden zonder nieuw veiligheidsrisico, en zodanig zijn dat politie en justitie deze kunnen herleiden.
Dit is uiteraard niet (in de eerste plaats) bedoeld voor het inloggen op webfora ofzo, maar kan wel nuttig zijn voor inloggen op sites waar je verplichtingen aangaat (webwinkels, telefoonbedrijven, banken etc).
Je zult ongetwijfeld weer komen met "maar dat kan nooit voor 100% werken", echter dat geldt voor iedere veiligheidsmaatregel en mag nooit een reden zijn om op je handen te gaan zitten en niets te doen.
12-07-2023, 14:24 door
Erik van Straten
Door Anoniem: Als je challenge zoals ik schreef de domeinnaam bevat, dan is dat niet mogelijk.
Als je met "challenge" een door de server verzonden "bericht" bedoelt, dan zegt een domeinnaam daarin helemaal niets. Een AitM kan zelf gegevens "verzinnen" of correcte gegevens van de echte server doorsturen. Die AitM kan zo'n bericht ook ondertekenen met diens private key, maar ook daar heb je niets aan; de AitM kan alles vervalsen.WebAuthn lost het AitM-probleem op door in de response van de client o.a. de domeinnaam (door de browser geregistreerd) op te nemen, en de gehele response digitaal te ondertekenen met de private key van het WebAuthn sleutelpaar. Een AitM kan daar niets mee:
• Als de AitM die response ongewijzigd doorstuurt naar de echte server, ziet die echte server (in de meeste gevallen [*]) een onjuiste domeinnaam;
• Als de AitM de domeinnaam in de response wijzigt, klopt de digitale handtekening niet meer (die hoort de echte WebAuthn server te controleren, gebruikmakend van de public key van het WebAuthn sleutelpaar).
[*] Niet indien een nepserver onterecht een certificaat voor de correcte domeinnaam heeft verkregen. Bijv. via een BPG-aanval of door het ongeautoriseerd kunnen wijzigen van een DNS-record van de echte server. Maar hiertegen helpen, vziw, alleen client certificaten (die overigens slecht door mobiele browsers worden ondersteund).
Door Anoniem: Je zult ongetwijfeld weer komen met "maar dat kan nooit voor 100% werken", echter dat geldt voor iedere veiligheidsmaatregel en mag nooit een reden zijn om op je handen te gaan zitten en niets te doen.
?? Volgens mij legde ik uit dat zo'n systeem bestaat (WebAuthn en wachtwoordmanagers die op domeinnamen checken). Bovendien gaat mijn topic niet uitsluitend over inloggen - maar over het, ook door ervaren internetters, niet betrouwbaar uit elkaar kunnen houden van nepwebsites en het origineel daarvan.Door Erik van Straten:
Ja die kan wel zoveel doen, maar dan kun je niet inloggen en de aanvaller kan niets met wat ie verzamelt.Door Anoniem: Als je challenge zoals ik schreef de domeinnaam bevat, dan is dat niet mogelijk.
Als je met "challenge" een door de server verzonden "bericht" bedoelt, dan zegt een domeinnaam daarin helemaal niets. Een AitM kan zelf gegevens "verzinnen" of correcte gegevens van de echte server doorsturen. Die AitM kan zo'n bericht ook ondertekenen met diens private key, maar ook daar heb je niets aan; de AitM kan alles vervalsen.Immers als die de challenge aanpast dan zal jouw browser de response voor die aangepaste challenge sturen en die is ongeldig als antwoord op de door de echte site gestuurde challenge.
De truuk is juist dat je uit die response niet het wachtwoord terug kunt rekenen.
Maar zoals ik al zei: het is vast wel opgelost (door buzzword-van-de-dag).
Alleen de uitrol naar alle websites waarop moet worden ingelogd, die komt er uiteraard niet.
"De groene balk" van vroeger. Voordat Chrome daaraan begon te sleutelen: dat de EV-aanvrager in de locatiebalk werd getoond.
12-07-2023, 16:16 door Anoniem: De truuk is juist dat je uit die response niet het wachtwoord terug kunt rekenen.
Dat is nauwelijks relevant als de aanvaller de huidige sessie gekaapt heeft (zoals ik al schreef).12-07-2023, 16:16 door Anoniem: Alleen de uitrol naar alle websites waarop moet worden ingelogd, die komt er uiteraard niet.
Daarom zijn wachtwoordmanagers die de domeinnaam checken m.i. een prima alternatief.13-07-2023, 06:57 door Anoniem: "De groene balk" van vroeger. Voordat Chrome daaraan begon te sleutelen: dat de EV-aanvrager in de locatiebalk werd getoond.
Ik zag gisteren in het subject in het certificaat van een Nederlandse organisatie het volgende (naam van de site verwijderd door mij):commonName: <naam>.nl
organizationName: Cloudflare, Inc.
stateOrProvinceName: Californië
localityName: San Francisco
countryName: US
Briljant.organizationName: Cloudflare, Inc.
stateOrProvinceName: Californië
localityName: San Francisco
countryName: US
Ter vergelijking, uit twee bij Cloudflare aangevraagde certificaten [16] (beide keren niet door Certificate Transparency geaccepteerd, maar dat kan ook bij Cloudflare anders uitpakken - sowieso draait o.a. Let's Encrypt daar hun hand zelden voor om) voor de (Chinese? scamsite [17]) lameers[.]com (die momenteel doorstuurt naar hxxps://www[.]lefames[.]com), de blokhaken '[' en ']' steeds toegevoegd door mij:
commonName: www[.]lameers[.]com
organizationName: Cloudflare, Inc.
stateOrProvinceName: Californië
localityName: San Francisco
countryName: US
organizationName: Cloudflare, Inc.
stateOrProvinceName: Californië
localityName: San Francisco
countryName: US
Áls je als Cloudflare OV certificaten uitgeeft, waarom doe je dan geen redelijke check of de aanvrager is wie hij/zij zegt te zijn (en geautoriseerd is om namens de organisatie een https servercertificaat aan te vragen), om vervolgens de juiste adresgegevens van die organisatie in het certificaat te zetten? En als je die check niet uitvoert, waarom zet je dan potentieel misleidende adresgegevens in zo'n certificaat?
We hebben overheden die identiteitsbewijzen en rijbewijzen uitgeven. Ook dat gaat niet altijd goed (voorbeelden: [18] t/m [20]), maar dat vinden we geen reden om er dan maar mee te stoppen; we hebben immers niks beters.
We moeten terug naar fatsoenlijke https servercertificaten waar (in elk geval kritische) bezoekers echt iets aan hebben. Feilloos kan niet, stukken beter wel.
[16] https://crt.sh/?q=lameers.com
[17] https://github.com/stamparm/maltrail/blob/master/trails/static/malware/apt_mustangpanda.txt
[18] https://nos.nl/artikel/2445277-opnieuw-haagse-ambtenaar-verdacht-van-het-uitgeven-valse-id-bewijzen
[19] https://nos.nl/artikel/2473396-politie-houdt-man-aan-met-vervalst-oekraiens-rijbewijs-van-boris-johnson
[20] https://static.standaard.be/Assets/Images_Upload/2015/09/16/b5bfdae8-5c83-11e5-8c16-41efac056b90_original.jpg
Door Erik van Straten:
Ja maar de aanvaller kan de sessie niet kapen door te rommelen met de challenge (zoals ik al schreef).12-07-2023, 16:16 door Anoniem: De truuk is juist dat je uit die response niet het wachtwoord terug kunt rekenen.
Dat is nauwelijks relevant als de aanvaller de huidige sessie gekaapt heeft (zoals ik al schreef).
13-07-2023, 16:13 door
Erik van Straten
Door Anoniem:
Als dat zou kloppen, kun je het wachtwoord plain-text verzenden (wat daarna sowieso gebeurt met het session-cookie o.i.d.). Wat is je punt?Door Erik van Straten:
Ja maar de aanvaller kan de sessie niet kapen door te rommelen met de challenge (zoals ik al schreef).12-07-2023, 16:16 door Anoniem: De truuk is juist dat je uit die response niet het wachtwoord terug kunt rekenen.
Dat is nauwelijks relevant als de aanvaller de huidige sessie gekaapt heeft (zoals ik al schreef).Door Erik van Straten:
Je kunt het plain-text wachtwoord (als aanvaller) niet weten, want dat is niet af te leiden uit de challenge en daarop verzonden response.Door Anoniem:
Als dat zou kloppen, kun je het wachtwoord plain-text verzenden (wat daarna sowieso gebeurt met het session-cookie o.i.d.). Wat is je punt?Door Erik van Straten:
Ja maar de aanvaller kan de sessie niet kapen door te rommelen met de challenge (zoals ik al schreef).12-07-2023, 16:16 door Anoniem: De truuk is juist dat je uit die response niet het wachtwoord terug kunt rekenen.
Dat is nauwelijks relevant als de aanvaller de huidige sessie gekaapt heeft (zoals ik al schreef).Het zou wel buitengewoon dom zijn om het vervolgens in een cookie te zetten.
14-07-2023, 14:47 door
Erik van Straten
Door Anoniem:
Het zou wel buitengewoon dom zijn om het vervolgens in een cookie te zetten.
Ben je me aan het trollen of zo? Zo niet, én indien je ervoor open staat om wat van een ander aan te nemen, wil ik e.e.a. (zodra mij dat uitkomt) wel met meer details toelichten - in een andere draad.Door Erik van Straten:
Je kunt het plain-text wachtwoord (als aanvaller) niet weten, want dat is niet af te leiden uit de challenge en daarop verzonden response.Door Anoniem:
Als dat zou kloppen, kun je het wachtwoord plain-text verzenden (wat daarna sowieso gebeurt met het session-cookie o.i.d.). Wat is je punt?Door Erik van Straten:
Ja maar de aanvaller kan de sessie niet kapen door te rommelen met de challenge (zoals ik al schreef).12-07-2023, 16:16 door Anoniem: De truuk is juist dat je uit die response niet het wachtwoord terug kunt rekenen.
Dat is nauwelijks relevant als de aanvaller de huidige sessie gekaapt heeft (zoals ik al schreef).Het zou wel buitengewoon dom zijn om het vervolgens in een cookie te zetten.
Reageren
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.
