Lokal Signatur Server (LLS)

Notat om it-sikkerhed og anvendelsen af Lokal Signatur Server

Formålet med dette dokument er at en række sikkerhedsmæssige aspekter affødt af den nye og bredere anvendelse af Lokal Signatur Server til NemID (LSS-til-NemID) end det oprindeligt var tiltænkt.

LSS løsningen blev i efteråret 2013 og foråret 2014 udviklet med det formål, at tilbyde brugere  adgang til at benytte deres NemID medarbejdersignatur fra mobile enheder. LSS var oprindeligt en ”work-around” for anvendelse af NemID medarbejdersignatur på mobile enheder. Enheder som ikke har Java og øvrige sikkerhedskomponenter installeret.

Med den nye LSS understøttelse i NemID Nøglefilsprogram udbredes LSS funktionaliteten på til alle platforme og ikke som en niche løsning for interne mobile enheder hos en given myndighed eller virksomhed.

1. Resumé

En Lokal Signatur Server muliggør at brugere kan logge på blandt andet nemlog-in.dk og andre offentlige services ved at benytte deres NemID medarbejdersignatur uden lokal nøglefil, men kun med deres brugernavn og adgangskode via en central signaturserver-løsning.

Med frigivelsen af NemID Nøglefilsprogram er LSS funktionaliteten nu indbygget i den almindelige logon metode for alle brugere af NemID medarbejdersignatur, uanset platform.

De konkrete sikkerhedsforhold kan opdeles i 3 punkter:

• 1. Forudsætningen for anvendelse af LSS er etablering af såkaldt skygge DNS for domænet lss-for-nemid-server.dk. SkyggeDNS er et meget oplagt mål for DNS spoofing og man-in-the-middle angreb. Det er en let adgang til at hente gyldige brugernavne og adgangskoder uden brugeren vil opdage kompromitteringen. 
  2. Kommunikationen mellem klient, LSS server og nemlog-in.dk forudsætter gyldige og trustede SSL certifikater. Da organisationen ikke selv ejer lss-for-nemid-server.dk domænet skal den selv udstedet et SSL certifikat til domænet samt efterfølgende omgå browsersikkerheden med opsætning af trust til det ”falske” og selv-udstedte SSL certifikat.Denne forudsætning er imod sikkerhedsanbefalinger og ”best practice” fra Certificate Authority (CA) branchen. Selv-udstedte SSL certifikater kan ikke benytte de meste sikre OV/EV SSL certifikater og der er stor risiko for at brugere vil opleve advarsler i browseren om manglende trust i tilfælde af nye klienter eller ændringer i eksisterende. 
  3. LSS dialogboksen muliggør i standard indstilling at man kan fremsøge gyldige brugernavne inden adgangskoden angives.Denne mulighed kan misbruges af enhver som kan få en maskine koblet til den lokale organisations netværk og dermed give adgang til viden omkring gyldige brugernavne i netværket

I det efterfølgende vil vi gennemgå de ovenstående punkter mere detaljeret og slutteligt komme med nogle konkrete anbefalinger til afhjælpning af sikkerhedsproblemerne.

2. Sikkerhedsforhold

1.      Man-in-the-middle

Det nye NemID Nøglefilsprogram forsøger med flere forskellige metoder til at fremfinde et NemID medarbejdercertifikat på klienten. En af disse metoder er at spørge klienten om den kender adresse på for domænet lss-for-nemid-server.dk og er det tilfældet og svarer lss-for-nemid-server.dk korrekt tilbage vil brugere blive re-dirigeret til LSS serveren og her bedt om at indtaste sit Windows domæne brugernavn og tilhørende adgangskode.

Proceduren for opsætningen er beskrevet på side 4 i punkt 2.2 i dokumentet ”Understøttelse af LSS til NemID I organisationen”[1].

Heri står der:

”Brugerens devices oversætter via den sikre netværksforbindelse til den lokale DNS server på organisationens netværk adressen for lss-for-nemid-server.dk til IP adressen på den lokale LSS for NemID server”

Det er vigtigt, at bemærke at dette domæne er ejet af Digitaliseringsstyrelsen og det er registreret i offentligt DNS hos DanDomain jævnfør nedenstående.

Domain: lss-for-nemid-server.dk
DNS: lss-for-nemid-server.dk
Registered: 2014-02-27
Expires: 2018-02-28
Registration period: 1 year
VID: no
Dnssec: Unsigned delegation
Status: Active

Registrant

Handle: D16993-DK
Name: Digitaliseringsstyrelsen
Address: Landgreven 4
Postalcode: 1301
City: København K
Country: DK
Phone: +45 33925200

Nameservers

Hostname: ns.dandomain.dk
Handle: DA49-DK
Hostname: ns2.dandomain.dk
Handle: DA49-DK
Hostname: ns3.dandomain.dk
Handle: DA49-DK

Forudsætningen for anvendelse af LSS er altså etablering af såkaldt skygge DNS for domænet lss-for-nemid-server.dk i ens egen organisation.

Tilbage i januar 2014 skrev vi følgende[2] til projektteamet for udarbejdelsen af LSS:

”Det forventes at slutbrugeren skal konfigurere en særlige intern skygge DNS service for at anvende TU pakken i sine nuværende form. Det er Ligas mangeårige erfaring med DNS i Enterprise netværk, at det kan medføre mange unødvendige support sager og frustration blandt slutbrugere når DNS service ikke fungere som forventet. Særligt skygge DNS er særligt vanskeligt for ikke kyndige netværksfolk. Liga opfordrer kraftigt projektet til at genoverveje DNS metoden med en metode som er enkelte at anvende for alle parter”

Problemstillingen ved ovenstående tekniske fejl er at, de leder direkte til at brugere ignorere browseradvarsler og at lokale it-medarbejder til sidst i frustration over fejl vælger at tilsidesætte system-sikkerhedsregler for at få kommunikationen til at fungere.

Denne situation er alvorlig og åbner for, at fremmede kan udnytte ”hullet” til at gennemføre DNS spoofing og dermed man-in-the-middle angreb på brugerne. Udbyttet af et sådan angreb er gyldige brugernavne og adgangskoder som efterfølgende frit kan bruges til adgang til eksempelvis FMK online og tilsvarende offentlige systemet med stærkt personfølsomme data. Husk på at den fremmede allerede er inde i netværket og dermed kan benytte organisationens egen rigtige LSS server. I denne LSS server ligger de gyldige NemID medarbejdercertifikater.

2. Falsk SSL certifikat

Kommunikationen mellem klient, LSS server og nemlog-in.dk forudsætter gyldige og trustede SSL certifikater. Da organisationen ikke selv ejer lss-for-nemid-server.dk domænet skal den selv udstedet et SSL certifikat til domænet samt efterfølgende omgå browsersikkerheden med opsætning af trust til det ”falske” og selv-udstedte SSL certifikat.

På side 5 i punkt 2.1.1 i dokumentet ”Understøttelse af LSS til NemID I organisationen” er der beskrevet følgende:

”Dette gøres lettest ved at I får udstedt et certifikat til denne adresse fra jeres egen CA eller jeres LSS leverandørs CA. Derefter skal I etablere i tillid til denne CA i de devices som skal anvendes”

Som dokumenteret i forrige punkt er det Digitaliseringsstyrelsen der er den officielle ejer af domænet lss-for-nemid-server.dk.

En almindelig regel for globale udstedere af SSL certifikater er, at man ikke kan udstede globalt anerkendte SSL certifikater hvis ikke man kan dokumentere ejerskab over domænet.

I forbindelse med udarbejdelse af dette notat har vi været i dialog med Head of Product Management Ingolf Rauh hos SwissSign i Zürich. SwissSign er en globalt anerkendt Certificate Authority (CA).

Han skriver:

a) A certificate should always be an identity thus not pretend to be an identity for another subject.

b) A public trustable certificate could show that the identity was checked by an audited authority (or even eIDAS trusted one). By use of pinning you could even limit the authentication to EV certificates of this audited authority. Otherwise everybody could pretend to issue the “right” certificate and fraud could happen.

c) If this is furthermore used as a intermediate server (thus the server first connects to the middle system and the middle system to the real end system) you have probably a “man-in-the-middle” functionality. For our certificates this would be forbidden e.g. by Mozilla etc.

Det er altså meget vigtigt, at brugeren altid kan stole indholdet af certifikatet og netop et offentligt certifikat dokumenterer overfor brugeren at identiteten er blevet omhyggeligt kontrolleret. 

Han skriver yderligere, at CA Browserforum kræver dette:

a) Either show that you have access to this domain by placing a “secret” (got from the CA) to <domain>/.well-known/pki-validation/… check.txt or htm

b) Either change a text string in the DNS entry

c) Either answer an automatic mail received by root@<domain>, hostmaster@<domain> …

d) Either show in the whois record that you are the owner or that this owner gives you autorisation. 

Det vil altså ikke være muligt for en uafhængig kommune eller region at få udstedet et officielt SSL certifikat til domænet med mindre dette aftales helt specifikt med domæne ejeren.

Brugen af selv-udstedet SSL certifikater kan let omgås og eksemplet herunder viser hvor konkret at Chrome browseren alligevel viser LSS login skærmbilledet uagtet at SSL advarslerne er meget tydelige.

Simpel omgåelse af SSL certifikat og alligevel vises LSS login til DanID produktionssystem

Tilbage i januar 2014 skrev vi eksplicit til projektgruppen for LSS projektet[3]

”Det forventes tilsvarende, at slutkunderne selv håndtere yderligere både rod-og klient SSL certifikater. På same måde som I punkt.2.b er dette ofte en faldgruppe til snesevis af fejlkonfigurationer og dermed frustration. Det opfordres at finde en sikkerhedsmodel der i så lilleomfang som mulig undgår individuelle SSL certifikater eller alternativt let kan anvende alm. globale standard SSL certifikater”

Omgåelsen af den basale SSL sikkerhedsmodel medfører, at brugerne ikke benytter den ”grønne hængelås” og at de lære at ignorer fundamentale it-sikkerhedsmæssige principper.

At være sløset med netop SSL sikkerhed åbner let op for misbrug, svindel og tab af data.

3. Fremsøgning af brugernavne

LSS dialogboksen muliggør i standard indstilling at man kan fremsøge gyldige brugernavne inden adgangskoden angives.

En basisfunktion i selve login dialogboksen er at brugeren indtaster sit brugernavn og klikker videre til adgangskoden. Med det samme vil dialogboksen fortage et opslag og se efter om brugeren har et gyldigt certifikat. Dette inden brugeren har indtastet sin adgangskode.

Det er i modstrid med ”best practice” indenfor brugervalidering, at tillade at man kan fremsøge gyldige brugernavne uden angivelse af som minimum en gyldig adgangskode.

Med denne metode aktiv kan den misbruges af enhver der har en maskine koblet til den lokale organisations netværk.

Funktionen kan endda kaldes direkte udenom selve NemID iFrame skærmbilledet:

Gyldig bruger med 3 certifikater