It-sikkerhedsekspert: Nets er skadeligt inkompetente

Version2-blogger og it-sikkerhedsekspert Henrik Kramshøj er forarget over, at NemID blev ramt så hårdt i marts og april, når ny dokumentation viser, at der også var angreb i januar og februar.

Version2 dokumenterede mandag, at NemID var udsat for DDoS-angreb i både januar og februar. Og det faktum, at det ikke var i marts, de første DDoS-angreb skete, kommer meget bag på it-sikkerhedsekspert og Version2-blogger Henrik Kramshøj, der er direktør for Solido Networks.

»Hvis NemID er blevet DDoS’et for flere måneder siden og stadig kan lægges ned med minimal indsats, er det bekymrende gange to,« siger Henrik Kramshøj og fortsætter:

»Hvis NemID er blevet DDoS’et i januar, men Nets ikke har reageret fornuftigt på det ved at opgradere systemet og kapaciteten, er de skadeligt inkompentente. Og det er bare endnu mere kritisabelt, når de er så vigtig en infrastruktur.«

Læs også: Nets: Vi begyndte først på DDoS-beskyttelse for NemID i januar

Det forarger Henrik Kramshøj, at det - trods kendskabet til DDoS-angreb i starten af året - ikke lykkedes Net at imødegå DDoS-angrebene bedre og hurtigere, da det igen ramte i marts og april.

»Nets burde have haft løsninger, der kunne træde i kraft, meget før end marts. De burde ikke kunne blive ramt så hårdt med simple midler af nogle, der ikke er hardcore-teknikere,« fastslår Henrik Kramshøj.

Læs også: NemID-hackere risikerer at hænge på kæmperegning for DDoS-angreb

Nets oplyser til Version2, at virksomheden i 2013 har arbejdet på at sikre systemet mod DDoS-angreb. Uanset om den indsats begyndte i starten af januar eller efter årets første DDoS-angreb, 25. januar, burde angrebene i marts og april ikke have haft så stor en påvirkning, understreger Henrik Kramshøj:

»For en virksomhed som Nets, der har arbejdet med sikkerhed i så mange år, burde tre måneder være nok til at indføre noget, der gør, at man ikke kan lægges ned uden videre.«

Han vurderer, at en simpel løsning, der udnytter det eksisterende udstyr til at foretage en grovsortering baseret på IP-adresser, vil koste omkring 75.000-100.000 kroner. En sådan løsning vil altså ifølge Henrik Kramshøj nemt kunne sættes i gang i løbet af et par måneder og er noget, som netværksfolkene i Nets burde kunne klare uden hjælp udefra.

»Herefter skal man vurdere, om man vil acceptere, at man risikerer at udelukke bestemte IP-adresser under angreb, for eksempel udenlandske IP-adresser. Hvis man ikke kan acceptere det, må man opgradere sin løsning,« siger Henrik Kramshøj og anslår, at en sådan løsning vil koste mindst et par hundrede tusinde om året.

Nets vil ikke komme med for mange detaljer om angrebene og de sikkerhedsforanstaltninger, man har og vil iværksætte. Det forstår Henrik Kramshøj som udgangspunkt godt, men han påpeger, at det kun er de allermest kritiske områder, der burde være skjult.

Læs også: Intern rapport afslører hemmeligholdte DDoS-angreb mod NemID

»Nets burde være ude og sige meget klart, at de har testprocedurer for sikkerhed, som i praksis tester systemet mod DDoS. De burde fremlægge, hvad de har gjort for at teste det, og herudover sige offentligt, at de udvider med en DDoS-performancetest. Det ville de kunne uden at hjælpe angriberne,« siger han.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (16)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Søren Vind

Et firma som CloudFlare (https://www.cloudflare.com/) har specialiseret sig i at sælge CDN-produkter der kan modstå temmelig store DDOS-angreb (de har vist rekorden for at beskytte mod det største offentligt kendte angreb). Nu tyder alt jo på at Nets ikke har taget fat i dem (eller noget lignende). Hvorfor er det lige at Nets ikke har gjort det? Er der betingelser i kontrakten der siger at al trafik skal oprinde i Danmark eller noget?

For denne slags infrastruktur er prisen endda også triviel, og alle ville sandsynligvis få bedre service som resultat (hint: de er også dygtige til at flytte bits).

Noget helt andet: Hvordan kan man glemme at konfigurere sin linux-kerne med tcp_syncookies=1 og så videre hvis man forestiller sig at man er professionel udbyder af kritisk infrastruktur?

  • 5
  • 2
Ole Wolf

Nets' mislykkede forsøg på implementering af sikker login er elendig på flere nivauer, men man skal bestemt ikke undervurdere inkompetencen hos dem, der godkendte Nets' produkt i stedet for at sige "duer ikke, væk!" om det.

  • 19
  • 2
Andri Oskarsson

Enig med Henrik. Det er skrammende at sådan et vigtigt system som har en kritisk fejlpunkt, ikke er testet for angreb, eller i hvert fald load-testet.

Desuden er jeg overbevist om at den gamle certifcate-løsning kunne videreudvikles sådan at den var nemmere for brugere. Så kunne man bruge nøglekortet som det andet lag.

  • 3
  • 0
Peter Mogensen

... er jo egentlig at der her er tale om et system som samtlige landets borgere forventes - nej faktisk er tvunget til (ifølge Corydon) - at have ubegrænset tillid til på niveau med en generel fuldmagt.

NemID er designet så det beror på at borgeren har grund til ubegrænset at stole på et bestemt privat firma. Et firma som ikke alene er drevet af bankerne (hvem vi næsten dagligt kan læse historier om er til for deres aktionærers skyld og ikke for kunderne), men nu kan vi altså også konkludere at der heller ikke er nogen speciel grund til at stole på dem rent teknisk.
...hvilket vi jo egentlig godt vidste i forvejen. Om ikke andet så da de forsøgte at bilde os ind at Java og at have adgang til at skrive på brugerens disk var pinedød nødvendigt.

Hvorfor skulle jeg have nogen som helst form for tillid til Nets?

  • 26
  • 1
Jesper Kildebogaard

Nu forstod jeg på en anden artikel forleden at Nitten også er rodet ind i sagen, så er det vel noget Windåse snask de benytter.

Hvis det er NNIT, du mener, så optrådte de i en anden artikel om NemID, fordi NNIT leverer Nem-Login, og derfor har været involveret i arbejdet med en ny NemID-løsning til mobile platforme.

NNIT har ikke noget at gøre med selve NemID.

vh.

Jesper, Version2

  • 10
  • 0
Mikkel Mondrup Kristensen

Noget helt andet: Hvordan kan man glemme at konfigurere sin linux-kerne med tcp_syncookies=1 og så videre hvis man forestiller sig at man er professionel udbyder af kritisk infrastruktur?

Syncookies har desværre den ulempe at de ikke skalere op til de angreb der er normale at se i dag, grundet nogle bottlenecks i kernen skalere de faktisk dårligere jo flere kerner du har.

Der har været tilløb til at få ordnet de problemer men de er desværre ikke fikset endnu

  • 2
  • 0
Jon Linde

for at være bekymret over NemID løsningen.

Hvis man har fulgt blot en lille smule med i den debat der har været - specielt på Ing/Version2 - og i øvrigt er i besiddelse af lidt sund fornuft og kritisk sans, er hele NemID konstellationen stærkt bekymrende.

Alene det faktum at enhver form for kritik konsekvent er blevet ignoreret eller blot afvist uden saglig begrundelse eller dokumentation, må være tilstrækkeligt grundlag for at en hvilken som helst person uanset kompetanceniveau begynder at famle febrilsk efter en sikkerhedssele (som også mangler i løsningen).

Faktisk kan jeg ikke komme i tanke om et eneste eksempel på at NET's eller politikere har forholdt sig til den - efter min opfattelse - faglige/tekniske/konceptuelle meget kraftige kritik som der har været af NemID.

NemID er blevet det barn, som end ikke dets forældre bør kunne elske.

Det her er jo ikke et spørgsmål om at en gruppe af borgere blot er paranoide eller bekymrede uden grund.
Med det antal katastrofale fejl som allerede er dokumenteret, bør spørgsmålet ikke være: "hvad kan vi gøre for at gøre NemID bedre".

Det rigtige spørgsmål bør være: "Hvordan kan vi hurtigst og billigst muligt ersatte NemID med en anden løsning og hvordan skal den løsning se ud?"

Det er ikke parania, når man VÉD at de er efter en.

  • 10
  • 1
René Løhde

Tak PHK,

Thumbs up, har savnet den observation i debatten.
Henrik Kramshøjs bemærkning om "...er noget, som netværksfolkene i Nets burde kunne klare uden hjælp udefra." glemmer tilsyneladende at tage højde for belastning på infrastrukturen før trafikken rammer Nets' domæne.

  • 0
  • 0
Henrik Kramshøj Blogger

PHK

Det gør man også, men inden man når så langt har pakkerne allerede overbelastet routere, linier osv.

Vi ved i sagens natur ikke ret meget om angrebene, der er flere angreb og formentlig flere strategier. En af disse kan sagtens være pakker med båndbredde i +10-20Gbit og stort antal pakker pr sekund. En DEL angreb idag vil dog være i kategorien mange request til en dyr operation, som så gentages mange gange - hvor det vil være relevant at kunne blokere på antal requests, samtidige forbindelser osv. Eller i kategorien slooooooow requests a la slowloris - hvor Varnish eksempelvis viste sig at være en god hjælp.

Min klare opfattelse er at sikringen mod angreb i alle nævnte kategorier har været for ringe. Så blot fordi Cloudflare snakker om 300Gbit angreb - og ingen i hele verden kan sikre sig mod dette, så er det ingen undskyldning for slet ikke at have noget forsvar.

René Løhde

Henrik Kramshøjs bemærkning om "...er noget, som netværksfolkene i Nets burde kunne klare uden hjælp udefra." glemmer tilsyneladende at tage højde for belastning på infrastrukturen før trafikken rammer Nets' domæne

Den kommentar er møntet på at de interne netværksfolk i organisationen selv burde være kyndige nok til at kende begreber som stateless filtering, BGP blackhole routing og kende kontaktinformationerne på deres benyttede internetudbydere. Det er nok ikke urealistisk at der er en CCIE blandt disse som kender features i både routere og firewalls.

Der betyder at du ret hurtigt ville kunne:

  • Udvælge danske ISP'er, herunder AS numre for disse - eller ihvertfald de primære vælg danmark under https://www.ripe.net/membership/indices/ - trafik og pakker fra disse accepteres og eventuelle angreb fra disse vil yderligere kunne efterforskes/anmeldes nemmere

  • Indføre stateless filtre for de vigtigste subnets og eventuelt blokere alt andet trafik til disse IP- adresser. Hint: en HTTP webserver behøver ofte kun port 80 og 443, og selv en lille Juniper SRX220 kan med stateless filtre snildt blokere 1Gbit traffik på alle andre porte (indtil porten er fyldt op). For ekstra success kan man bede sine upstreams indføre selvsamme filtre for disse IP'er. Specielt NemID forestiller jeg mig ikke ændre porte og setup hele tiden.

  • Indføre netflow i netværket for synlighed i trafikken som kommer ind, som igen bruges til at blokere og afvise traffik. Nej, chinanet prefix x.y.z kan formentlig afvises ved døren

  • Have flere internetforbindelser - ved at have en 1Gbit til en transit udbyder - the world - og en 1Gbit til DIX ville sikre at selvom transit-linket løb fuld ville der stadig kunne serviceres på det andet link til danske kunder hos dem man nå via dette link. NB: dette er forsimplet og DIX er blot et eksempel, men en bredere peering strategi og et udvalg af routere - så ville man som MINIMUM kunne servicere direkte kunder af danske firmaer i Danmark for en ikke uoverskuelig sum penge.

  • Der er også hos alle de store udbydere mulighed for at benytte deres blackhole service, eksempelvis som beskrevet hos Cogent:

    The Cogent Black Hole server will allow customers to announce a /32 route
    to Cogent and have all traffic to that network blocked at Cogents backbone.
    All peers on the Cogent black hole server require a password and IP address
    from your network for Cogent to peer with.
  • det vil blackhole trafikken til bestemte adresser - VIA den peer, men ikke via andre peers

Jeg har ingen viden Nets infrastruktur, men det er nogle af de tiltage man kunne iværksætte med de eksisterende medarbejdere og viden.

DERNÆST kunne man begynde at indkøbe dyre DDoS specieliserede løsninger, eller udvikle selv - med formål at tilbyde mere fintmasket filtrering.

  • 11
  • 0
Michael Nielsen

Design det rigtig, og DOS er bare en curiositet.. Det er kun den tvungne centralisering der gør systemet sårbar over for DOS angreb.

Lige som det også gør dem sårbare over for phishing (aka MITM angreb), noget som var forudsagt flere måneder før NemID blev påtvungen alle Danskere...

Sørgeligt at man ikke kiggede på nogen af de analyser de fik smidt i hovedet..

Viser bare vi har folk der bestemmer over os, som ikke har kompetancerne til at tage de rigtige beslutninger, men har magten til at bestemme - gælder både embedsmænd, og politikere.

  • 3
  • 0
Sascha Dibbern

Efter at låse mig ud fra min netbank i 24 timer (pga. forkert password) noget tid siden, undrer jeg mig, hvorfor ingen script-kiddie har prøvet at køre en CPR-bombe mod NemID/Nets.

Hvad er CPR-bomben? CPR-bomben er den situation hvor angriberen har opnået 2 mål:
1. Angriberen er kommet i besiddelse af alle/de fleste CPR-numre af brugere forvaltet af NemID
2. Lockout: Angriberen forstyrrer/forhindrer brugeren i brug af NemID ved at låse brugeren ud pga. gentagne fejllogin.

Præmisser for at bomben kan virke
1. En bruger må anvende sit selvvalgte NemID navn eller CPR-nummeren som ID for at logge ind. CPR-nummeren er et problem.
2. En bruger bliver låst ud for 24 timer efter 4 fejlagtige loginforsøg
3. Observeret authentificeringstid for login med forkert / ikke eksisterende CPR-nummer er kortere en med rigtig CPR-nummer (men forkert password). En (subjektiv) kort test af min CPR og en forkert CPR viser en tendens i den retning.
4. Hvert CPR-dato (op til oktober 2007) har maksimum 540 mulige kontrolcifre. (Der er vel heller ikke interessant for en angriber at nedlægge brugen NemID or børn ;-) )

Scenario A (for mål 1)
En CPR-årgang har 197610 potentielle numre. At identificere alle gyldige CPR-numre i en CPR-årgang på baggrund af kørselstid af en authentifikationsfejl vil kræve behagelige 2,28 forsøg pr. sekund over en 24 timers indsamlingskørsel... Og vil angriberen lave noget særligt postyr (og spare tid) så vælger angriberen bare nogen særlige årgange (som dem med pengene i banken) eller et bestemt køn.

Scenario B (mål 1)
Hvis præmisse 3 ikke holder, dvs. Nets randomizer svartiderne udafhængig om gyldigheden for CPR-nummeren, så vil muligvis stadig 4 fejlforsøg afsløre validiteten af CPR-nummeren (ikke afprøvet) pga evt. anden fejl-meddelese (dvs. man kan jo ikke låse en ikke eksisterende CPR).

Scenario C: (mål 2)
Hvis angriberen har formået at indsamle nok CPR-numre så sætter angriberen bare et bot-net igang for den daglig lockout af NemID-brugere.

Ovenstående kræver vist ikke mere end nogen få scripts ... og jeg håber at jeg ligger forkert med min analyse, og jeg ikke motiverer nogen script-kiddies at ruinere deres fremtid ved at prøve sådan ond angreb mod lille Danmark.

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize