I denne kommentaren svarer Jonny Rein Eriksen på uttalelser som Vipps kom med i en artikkel digi.no publiserte fredag 22. mars 2019. Uttalelsene ble innhentet av digi.no etter den første kommentaren til Jonny Rein Eriksen, som digi.no også publiserte den 22. mars 2019.
Først og fremst vil jeg gjerne si at det å offentliggjøre sårbarheter før de har blitt fikset, er noe jeg har forsøkt å unngå. Jeg er tilhenger av responsible disclosure og føler et ansvar når jeg ser alvorlige sikkerhetssvakheter i en løsning som størsteparten av Norges befolkning bruker.
Første rapport ble sendt til BankID Norge (Vipps) for ett år siden, hvor sikkerhetssvakheten i vanlig BankID ble dokumentert. En måned senere ble rapport nummer to sendt hvor sårbarheten i BankID på mobil ble påpekt. Etter rapportene, to samtaler og flere e-poster, ble det klart at der var liten forståelse for problemstillingen.
Jeg valgte derfor å gå til DNBs sikkerhetsgruppe med rapporten og et sikkerhetshull jeg hadde funnet i DNB Finger ID. I møte med dem tok de sikkerhetssvakhetene alvorlig og la raskt en plan for å fikse sin app. I tillegg ba jeg dem bistå i kommunikasjonen med Vipps.
Så ut som det førte frem
Det gjorde de, og et øyeblikk så det ut som dette førte frem, da jeg i ettertid mottok en mail hvor Vipps blant annet sa følgende:
«Hva angår tiltak, så har det tidligere vært publisert en liste over godkjente brukersteder. Denne ble tatt ned, da ingen benyttet denne listen. I lys av din rapport og begrunnelse, ser vi nå på muligheten for å publisere denne igjen. Tiltak som sms/epost bekreftelse for siste bruk (autentisering/signering) er noe vi har dialog med bankene om.»
Jeg kunne ikke med beste vilje anbefale disse tiltakene. Det ville vært urimelig overfor forbrukerne å måtte sjekke om nettstedet hvor BankID skulle benyttes var et godkjent brukersted. Å motta en sms/epost i etterkant hver gang en har brukt BankID, ville fort bli oppfattet som unødvendig støy. I det hele tatt ville denne løsningen ha skjøvet urimelig mye av ansvaret over på forbrukerne. Jeg tilbød å bistå i valg av løsning, men fikk aldri noe svar.
Feil design
Hovedårsak til at Vipps må tenke på slike tiltak, er at løsningen i utgangspunktet er feil designet. Å vise frem et egenprodusert brukerstedssertifikat i en iframe, og fortelle brukerne at dette er et sikkerhetselement som de kan stole på og derfor oppgi brukernavn og passord, bryter sikkerhetsmodellen i en nettleser.
Ifølge Wikipedia: «The contents of a web page are arbitrary and controlled by the entity owning the domain name displayed in the address bar. If HTTPS is used, then encryption is used to secure against attackers with access to the network from changing the page contents en route. When presented with a password field on a web page, a user is supposed to look at the address bar to determine whether the domain name in the address bar is the correct place to send the password.[30] For example, for Google's single sign-on system (used on e.g. youtube.com), the user should always check that the address bar says "https://accounts.google.com" before inputting their password.
An un-compromised browser guarantees that the address bar is correct. This guarantee is one reason why browsers will generally display a warning when entering fullscreen mode, on top of where the address bar would normally be, so that a fullscreen website cannot make a fake browser user interface with a fake address bar.»
Bryter sikkerhetsmodellen
Det viktigste sikkerhetselementet i nettleseren som er synlig for brukeren, er adressefeltet. Det forteller brukeren hvem han kommuniserer med, samt om kommunikasjonen er kryptert. Med BankID bruker en ikke domenenavn i adressefeltet for å avgjøre hvor en sender innlogging, siden BankID lastes gjennom en iframe. Det gjør at brukeren ikke kan se hvor BankID-dialogen kommer fra og dermed heller ikke hvor autentiseringsinfo sendes.
I stedet forsøker BankID å vise dette ved å presentere sitt eget brukerstedsertifikat og bryter dermed sikkerhetsmodellen. En bruker har ingen mulighet til å sjekke gyldigheten av dette, og automatisk sjekk kan ikke utføres av browseren. Et falskt BankID-sertifikat presentert her ser derfor like gyldig ut som et ekte.
Det er nærliggende å sammenligne BankIDs brukerstedssertifikater med sertifikatinformasjon som vises i adressefeltet i nettleseren. Begge er basert på Public Key Infrastructure (PKI) og asymmetrisk kryptografi for å sikre kommunikasjon over åpne nett.
Stor forskjell
En stor forskjell ligger i valideringen som gjøres av nettleseren: Når en aksesserer en webserver over HTTPS, så lastes sertifikatet ned fra server i TLS handshake. Deretter verifiseres sertifikatet mot rotsertifikatene som ligger på brukers maskin. Hvis sertifikatet ikke kan valideres, vil du få tydelige advarsler mot å gå inn på nettstedet (se https://self-signed.badssl.com/ ). Er sertifikatet gyldig, så vises hengelås. Benyttes et EV-sertifikat så får en i tillegg se firmanavn og landkode.
Når en browser viser frem sertifikatinformasjon, så gjøres dette i browserens egen «chrome». Dette er et område av brukergrensesnittet som HTML/JS ikke kan manipulere. Dermed er brukeren trygg på at sertifikatinformasjonen som vises, er korrekt.
Et kompromittert nettsted som har en falsk BankID-iframe, forleder bruker til å tro at kommunikasjon skjer mot BankIDs webserver. BankIDs brukerstedsertifikat fremstår som korrekt, og der er ingen mulighet for å validere dette. Når bruker så oppgir personnummer, engangskode og passord, så vil Man-In-The-Middle ta imot og gjenbruke disse for å fullføre angrepet.
Hvordan vil en riktig designet løsning kunne se ut?
Det enkleste ville vært en knapp på et BankID brukersted som sa «Logg inn med BankID». Denne kunne ledet til https://www.bankid.no/autentisering/, hvor en kunne ha presentert noe tilsvarende BankID-iframe, omtrent slik som den ser ut i dag. Brukeren kunne oppgi brukernavn, engangskode og passord og samtidig vite at det kan han trygt gjøre så lenge https://www.bankid.no/ vises i addressefeltet.
Det ville vært en enkel og forståelig regel å følge, og BankID kunne trygt skalert til tusenvis av brukersteder uten å bryte nettleserens sikkerhetsmodell. Der er mange eksempler på eID-systemer som oppfører seg slik.
Svar på kommentarene fra Vipps:
Phishing
«Vi oppfatter hovedpunktet til Jonny til å være utfordringen med å identifisere legitime brukersteder av BankID fra en Phishing-side med den konsekvens at en angriper kan logge seg på kontoen til en annen bruker. For en bruker er det mulig å se at dette er et gyldig brukersted av BankID. Dette er synlig på førstesiden av innloggingsdialogen. Her er det viktig at brukeren har et bevisst forhold til om dette stemmer overens med nettsiden de er på.»
Hovedpunkt er at for et kompromittert eksisterende BankID-brukersted, er det ikke mulig for en bruker å skille mellom en falsk BankID-iframe og en ekte, da disse vil se identiske ut. I tillegg gjør løsningsvalget det mulig å introdusere BankID-iframe til andre kompromitterte nettsteder som ikke bruker BankID til vanlig. Ved et bedre design ville dette ikke vært mulig.
BankID på mobil
«Utfordringene som påpekes rundt BankID på mobil i sammenligning med svensk BankID er vi uenige i. Referanseordene i BankID på Mobil er en del av dybdeforsvaret og kommer i tillegg til visningen av brukerstedet. Vi deler ikke oppfatningen om at “de fleste ikke legger merke til denne informasjonen” og ser på synliggjøring av brukersted som en viktig del av det å etablere kontekst for brukeren. I tillegg må brukeren også ta et aktivt valg om innlogging ved å taste PIN-kode før innloggingen gjennomføres.»
Hvor mange autorisasjoner har blitt avbrutt fordi brukerstedsertifikat og nettside ikke stemte overens?
Jeg er enig i at «de fleste» er feil ordbruk, siden jeg ikke kan bevise dette. Men jeg vil gjerne spørre om følgende: Hvor mange autorisasjoner har blitt avbrutt fordi brukerstedsertifikat og nettside ikke stemte overens? Og hvor mange fullførte autentisering på tross av dette?
Ser vi på noen av guidene til bruk av BankID på mobil finner vi følgende eksempler:
«Klikk deretter på pilen til høyre for BankID på mobil for å gå videre og motta referanse på mobilen din. Sjekk at referanseordene stemmer overens og tast ID-pin på mobilen som vanlig.» (Difi)
Opplysning om hvilken bank som har utstedt BankID-identiteten
«Dette er helt korrekt og per design da dette er det som gir deg mulighet til å velge hvilken engangskode-mekanisme du ønsker å benytte. Vi har flere brukere som har flere metoder å velge mellom og trenger da å informere om hvilken mekanisme som skal benyttes. Dette er et godt eksempel på at man må kontinuerlig gjøre en avveining av brukervennlighet og sikkerhet.»
Dette utgjør fortsatt en datalekkasje som kan bistå en angriper. En mulig måte å gjøre dette på som ville redusert denne, vil være å indikere hvilken mekanisme som skal benyttes kun i de tilfeller hvor en bruker har flere mekanismer å velge mellom.
Bruk av samme brukernavn og passord på flere brukersteder er en risiko
«I utgangspunktet er vi helt enige i at man ikke bør gjenbruke passord på forskjellige steder da dette gir en risiko for at uvedkommende får tak i passordet gjennom ulike datalekkasjer, implementasjonsfeil eller annet på ett av disse nettstedene.
Ved bruk av BankID får derimot aldri brukerstedet tilgang til denne informasjonen. I stedet stoler brukerstedene på at BankID gjør en tilstrekkelig autentisering av brukeren og kan ved behov få kryptografiske bevis for dette. På denne måten er BankID en klarert tredjepart som er revidert i henhold til europeisk lov og internasjonale standarder for å håndtere denne typen informasjon og prosesser.»
Som beskrevet ovenfor, så bryter BankID-iframe sikkerhetsmodellen i nettleseren ved å spørre om autentiseringsinformasjon i en iframe. Et kompromittert nettsted med en falsk BankID-iframe gir angriper anledning til å hente ut denne. Hvorfor er Vipps villige til å stole på såpass mange tredjeparter?
En definisjon på MITM-angrep
«Jonny hevder i sitt eksempel at dette er et såkalt Man-In-The-Middle-angrep (MITM). Det er det derimot ikke. MITM er et angrep hvor en angriper kontrollerer kommunikasjonen mellom to parter og kan gjøre endringer på denne. Dette utgjør spesielt en trussel ved bruk av usikre trådløse nett. Bruk av kryptert transport (SSL/HTTPS) som de fleste nettsider benytter, bidrar til å minske denne trusselen, selv om det i kombinasjon med angrep mot SSL-infrastruktur eller nøkkellager på brukerens PC fremdeles kan være en trussel.»
Sikkerhetsselskapet Rapid7 skriver: «Man-in-the-middle attacks are a common type of cybersecurity attack that allows attackers to eavesdrop on the communication between two targets. The attack takes place in between two legitimately communicating hosts, allowing the attacker to “listen” to a conversation they should normally not be able to listen to, hence the name “man-in-the-middle” .»
Kommunikasjon med falsk BankID-iframe til MITM ser legitim ut for en bruker. Etter å ha oppgitt sine data, kommer brukeren inn på nettstedet. Tilsvarende så vil MITM oppføre seg legitimt ovenfor sin BankID-iframe. Han gjenbruker informasjonen som bruker gir ham innen engangskoden utløper, slik at autentiseringsprosessen forløper som forventet.
«Han beskriver også en trussel i svært spesifikt område, mens vi jobber langt bredere og dypere med sikkerhet.»
Det er som oftest det svakeste punktet som vil bli angrepet.
