KOMMENTAR: – Hvorfor er Vipps villige til å stole på såpass mange tredjeparter?

[Redaksjonen.]

KOMMENTAR: – Hvorfor er Vipps villige til å stole på såpass mange tredjeparter?

[1TR4R69Q]

Jeg er i utgangspunktet enig i at modellen med å bruke en iframe gjøre det vanskelig for brukeren å fastslå om dialogen som vises er reell eller ikke. En full redirect innom www.bankid.no/autentisering vil være flere hakk bedre, men lenker som www.bankid.no.zxy.ru/autentisering vil fremdeles være nok til å lure mange. Phishing vil være en del av det generelle trussebildet enhver nettbasert authX-løsning vil måtte forholde seg til, og det er urimelig å anse disse som "sikkerhetshull".

 

Men det mest selsomme med hele denne tiraden fra Eriksen er det såkalte MITM-angrepet på BankID på mobil beskrevet i den første saken, hvor en falsk iframe proxyer kall til en ekte og henter ut navn på brukersted og kodeord for å på den måten lure brukeren til å tro at hele dialogen er ekte. For at dette skal fungere forutsettes det en kompromittert browser, og er således er hele "angrepet" fullstendig uinteressant. Folk flest har ikke installert browser extensions som stripper vekk sikkerhetsmekanismer som content-security-policy og x-frame-options, som selvfølgelig finnes nettopp for å hindre (bl.a.) denne angrepsvektoren.

 

Hvis man tar utgangspunkt i at brukeren på forhånd må lures til å installere noe er jo all bets off. Hvorfor ikke da bare installere en keylogger, et nytt rotsertifikat du kontrollerer eller hvilken som helst av de ørten rootkits som finnes der ute. Å kalle det som har "installer X på offerets PC" som trinn 1 for et "sikkerhetshull", grenser til det uredelige.

[Jonny Rein Eriksen]

Men det mest selsomme med hele denne tiraden fra Eriksen er det såkalte MITM-angrepet på BankID på mobil beskrevet i den første saken, hvor en falsk iframe proxyer kall til en ekte og henter ut navn på brukersted og kodeord for å på den måten lure brukeren til å tro at hele dialogen er ekte. For at dette skal fungere forutsettes det en kompromittert browser, og er således er hele "angrepet" fullstendig uinteressant. Folk flest har ikke installert browser extensions som stripper vekk sikkerhetsmekanismer som content-security-policy og x-frame-options, som selvfølgelig finnes nettopp for å hindre (bl.a.) denne angrepsvektoren.

 

Les gjerne den første artikkelen en gang til. Jeg skriver blant annet:

 

Eksempelet er kun ment å illustrere punktet nevnt tidligere: «Et siste alternativ er å angripe en eksisterende tjeneste som ikke bruker BankID til vanlig, for så å endre denne slik at en falsk BankID-iframe blir injisert på et passende sted. Eksempelvis innloggingssidene på en avis eller et forum.»

 

Demonstrasjonen er utført lokalt, men illustrerer et angrep utført mot f.eks. webserver.

[Ragnar Stølsmark]

Det er helt legitime bekymringer du tar opp her. Det Bankid burde gjort er å fase ut den iframe-baserte løsningen til fordel for den nye versjonen av bankid basert på standardprotokollen OpenID Connect, slik de gjorde med den forhatte Java-baserte løsningen de hadde før.

Endret 23. mars 2019 av Ragnar Stølsmark

[1TR4R69Q]

I den originale artikkelen står det:

 

BankID på mobil viser to referanse-ord i BankID-iframe og på mobil. Brukerne er opplært til å oppgi koden sin hvis disse samsvarer.

 

Et angrep kan forbigå dette ved å videresende referanseord fra en original iframe kontrollert av angriper, til en falsk iframe som bruker har fått servert. At referanseord vises et tidels sekund senere enn normalt, er vanskelig å oppdage.

 

Det er veldig uklart hvordan du mener dette skal fungere. En angriper som f.eks. har klart å injisere javascript på nabobil.no, vil selvfølgelig kunne flytte den originale iframen ut at av viewporten og serve opp en falsk iframe som ser identisk ut.

 

Men han vil ikke kunne skrive eller lese til den originale iframen, og har dermed ikke mulighet til å "videresende referanseordene" pga same origin policy (med mindre du har en kompromittert browser). Og da klapper hele dette "angrepet" sammen.

 

Det at iframe i det hele tatt blir brukt av BankID er definitivt noe som kan problematiseres, siden det gjør det vanskeligere å oppdage phishing. Her burde du ha stoppet. Resten artikkelen lukter av FUD, og sammen med replikken fra Vipps-representanten (hvor hun tar i bruk ordet "useriøs") får man inntrykket av at dialogen dere i mellom ikke har vært altfor trivelig og at man nå bare er ute etter å kaste steine på hverandre. Og selvfølgelig er Digi velvillige og nyttige idioter med å gi beefen deres masse spalteplass. Rent sikkerhetsfaglig er den dessverre ganske uinteressant.

[G]

Det mest negative med BankID som jeg har opplevd er at man kan bli bedt om å endre passord. Dette øker ikke sikkerheten nevneverdig. Og er mest for et irritasjonmoment å regne.

 

(obs, jeg har brukt setningene ovenfor også i en annen diskusjonstråd, da jeg tror BankID leser det enklere der. Oppdaget den andre artikkeltråden først etterpå)

Endret 23. mars 2019 av G

[0laf]

Det er veldig uklart hvordan du mener dette skal fungere. En angriper som f.eks. har klart å injisere javascript på nabobil.no, vil selvfølgelig kunne flytte den originale iframen ut at av viewporten og serve opp en falsk iframe som ser identisk ut.

 

Men han vil ikke kunne skrive eller lese til den originale iframen, og har dermed ikke mulighet til å "videresende referanseordene" pga same origin policy (med mindre du har en kompromittert browser). Og da klapper hele dette "angrepet" sammen.

Elementært, jeg setter inn en falsk iframe på en kompromittert nettside, brukeren ser ikke forskjell, taster inn all info, som videresendes rett til meg.

 

Jeg kan deretter åpne BankID på min maskin, taste inn brukerens info, å logge inn eller verifisere en helt annen betaling, med annet beløp, med denne brukerens info, så fremt jeg gjør det innen en viss tid, jeg er med andre ord mannen i midten.

 

Det finnes flere måter å begrense slike angrep, man kan lage en profil av brukerens systemer, altså OS, nettleser, installerte plugins m.m. og dersom det avviker vesentlig innen tiden før BankID-koden utløper, be om ytterligere autorisasjon osv. Pinning av sertifikater er også mulig, men ingen av de teknikkene fungerer dersom hele BankID-vinduet og sertifikatet uansett er falskt.

 

Er enig i at ut fra et sikkerhetsperspektiv burde nettleseren omdirigere å benytte SSL-sertifikat i stedet, ikke alt trenger å lastes dynamisk her i verden.

Endret 23. mars 2019 av 0laf

[G]

BankID tilbakeviser det som en sårbarhet. Forstå det den som kan 0laf.

 

https://www.diskusjon.no/index.php?showtopic=1841777

[StigVidar]

Vipps sin håndtering av dette forundrer meg, men er ikke overraskende. Jeg har selv rapportert svakheter til de og bare fått svada tilbake.

 

I Vipps appen kan en logge på med fingeravtrykk og det gjøres ingen sjekk om nye fingeravtrykk er lagt til. Husets sønn/datter som bruker mors mobil til spill og kjenner pin-koden, kan legge til sitt fingeravtrykk og åpne Vipps. Slik var det i januar og jeg vet ikke om det er endret nå.

 

I Sbanken sin app er det sjekk på om fingeravtrykk er endret eller lagt til og den deaktiverer pålogging med finger.

 

Dette ble nevnt, men de virket helt uinteresserte.

[Anders Jensen]

Hvis man outsourcer feil del av løsningen så blir det gjerne mangler i den strategiske forståelsen. Jeg tror det er hva vi ser konturen av her.

[joakimb]

"Det er som oftest det svakeste punktet som vil bli angrepet."

 

Dermed er dette en ikke-sak da? Eller mener OP at bankid sin bruk av iframes er det svakeste punktet? Det vil i så fall være en dristig påstand som jeg tviler på at han kan underbygge.

[Gjest Slettet-JC3FPBwS]

«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.

 

Veldig riktig!

[Jonny Rein Eriksen]

Det er veldig uklart hvordan du mener dette skal fungere. En angriper som f.eks. har klart å injisere javascript på nabobil.no, vil selvfølgelig kunne flytte den originale iframen ut at av viewporten og serve opp en falsk iframe som ser identisk ut.

 

Men han vil ikke kunne skrive eller lese til den originale iframen, og har dermed ikke mulighet til å "videresende referanseordene" pga same origin policy (med mindre du har en kompromittert browser). Og da klapper hele dette "angrepet" sammen.

 

For at dette skal fungere så må kompromittert webserver laste en falsk BankID iframe som åpner en websocket til angripers webserver ifølge same-origin policy. Dette er tilsvarende det som ble konseptuelt demonstrert for vanlig BankID. Når bruker så oppgir fødselsdato og telefonnummer så sendes dette til angripers webserver. Angriper bruker en extension på sin browser som er laget for å kommunisere mellom angripers webserver og angripers nettleser. Således mottar han telefonnummer og fødselsdato, injiserer dette i ekte BankID iframe ved hjelp av extension og en går videre til steg to. Straks referanseord dukker opp i angripers BankID iframe så leses dette fra DOM ved hjelp av extension. Referanseord sendes deretter tilbake til angripers webserver som igjen proxyer dette til falsk BankID iframe.

 

Dette har jeg dessverre ikke forklart i original artikkel, så at dette fremstår som uklart er berettiget kritikk.