Lokal Signatur Server (LLS)

Lokal Signatur Server (LLS) notat om sikkerhed og anvendelse.

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.

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.

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

 

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

Gyldig bruger med 3 certifikater.

Gyldig bruger med 3 certifikater

 

Ugyldig bruger.

Ugyldig bruger

3. Genskabelse

Det er enkelt at reproducere et setup som muliggør eksemplerne omtalt det det forrige afsnit.

  1. Download “LSS test stub source .Net”[4] fra Digitaliseringsstyrelsens side omkring LSS for NemID Service Provider package.
  2. Installer pakken på en standard Microsoft Windows Information Server (IIS)
  3. Opsæt SSL på en IIS server man selv kontrollere. Servere kan være hvor som helst i verdenen.
  4. Opsæt DNS enten centralt i det lokale LAN eller direkte i den enkelte Windows maskine lokale hosts fil (ligger normalt i C:\Windows\System32\drivers\etc\hosts).
  5. Opsæt trust til server SSL certifikatet på den lokale Windows maskine.
  6. Få en bruger til at åben en browser på den lokale Windows maskine og kald en side som benytter nemlog-in.dk

 

  • a) Send besked til brugeren om at der opstået en fejl og omdiriger herefter brugeren til den korrekte LSS server.
  • b) Man har nu et gyldigt brugernavn samt dennes adgangskode til både den pågældendes NemID medarbejdersignatur samt – med stor sandsynlighed – også adgangskoden til netværkes Active Directory. Brugeren vil fortsætte uden at tænke videre over hvad der gik galt.

Man kan som tidligere nævnt designe sit angreb på LSS infrastrukturen på flere måder. Eksemplet ovenfor forudsætter, at man har lokal administrator adgang til den enkelte Windows maskine. Det er ofte ikke vanskeligt at få adgang via zero-day væktøjer. Alternative angrebsvinkler kan være falske DHCP servere, WiFi access punkter eller andre gængse man-in-the-middle angrebsmetoder.

4. Anbefalinger

I ovenstående 3 punkter forsøger vi at forklare at den nuværende horisontale model med LSS løsningen er it-sikkerhedsmæssigt skrøbelig og vi vil derfor forsøge at beskrive nogle alternative løsninger.

 

1. Smart card anvendelse

Den simpleste løsning er at flyttet DNS kravet til at pege på localhost og IP 127.0.0.1. Svaret her er en hardware token med et smart card. Et smart card er netop en lokal signatur server.

Løsningen kan implementeres direkte i den nuværende LSS API procesmodel, men vil kræve særligt software på klienten. På mobile enheder er dette typisk allerede tilfældet hvorfor implikationen for brugeren er begrænset.

Smart card er allerede understøttet af NemID Nøglefilsprogrammet på Windows platformen.

 

2. 2-vejs SSL

Nets DanID tilbyder særlige funktionscertifikater til sikker applikationskommunikation.

Denne certifikattype kan udvides til at håndtere et certifikat som indeholder navn og IP adresse på den enkelte organisations LSS server. Derved er DNS spoofing og man-in-the-middle gjort væsentligt vanskeligere.

Certifikatet og dets nøgle distribueres til klientmaskiner med almindelige Enterprise systemmanagement værktøjer og LSS dialogboksen indlæses kun hvis der er etableret 2-vejs SSL mellem partnerne.

 

3. Trust via 3-part og COTS software

I projektets oprindelige formål var beskrevet andre autentifikationsmetoder end kun en JavaScript iFrame. Disse kunne være, men ikke udelukkende, OIOSAML & SAML2, OAUTH mv.

Med anvendelse af såkaldte COTS (Commercial off-the-shelf) single sign-on løsninger vil det være muligt at etablere både en sikker og tilsvarende brugervenlig løsning.

5. Afslutningen

Vi har dette notat bevidst undladt direkte referencer til gængse nationale og internationale regler og standarder.

Disse er blandt andet, men ikke udelukkende, EU Persondataforordning (GDPR), eIDAS, ISO 27001 og National Standard for Identiteters Sikringsniveauer (NSIS).Baggrunden herfor skyldes, at det ville have forsinket dette notat betydeligt. Vi har vurderet at budskabet var vigtigere end specifikke juridiske referencer.

6.    Kontaktoplysninger

Liga Software ApS
International House
Center Boulevard 5
2300 København S

Bjarke Alling, +45 40 13 91 05, ba@liga.com
Uffe Bager, +45 20 97 78 08, ub@liga.com