Eksperter: Uforståeligt at CSC's server ikke var krypteret

Det er dybt kritisabelt, at CSC ikke havde krypteret sin internet FTP-server og lige så kritisabelt, at selskabet ikke reagerer på henvendelser om huller i adgangen til deres server, siger flere eksperter. CSC er endnu tavse.

Flere eksperter Version2 har talt med forstår simpelthen ikke, hvordan CSC kunne have en server stående, som ikke var krypteret.

»En intern server bør være krypteret. Især hvis den ligger inde med følsomme oplysninger,« siger Lars Ramkilde Knudsen, forsker i kryptologi og sikkerhed ved DTU Compute.
»Kryptering er ikke nogen ny opfindelse, og hvis det passer, at CSC ikke havde krypteret sin FTP-server, er det simpelthen både for dumt og for dårligt,« siger han til Version2.

CSC besidder en stor mængde data om danskerne, og Lars Ramkilde Knudsen finder det bestemt ikke betryggende, hvis virksomheden ikke har mere styr på sikkerheden.

»Desværre er det sådan mange steder i det danske system. Vi stoler på hinanden og tror ikke, det er nødvendigt at kryptere. Men det er det,« siger han.

Samme reaktion kommer fra Version2-blogger og it-specialist Poul-Henning Kamp, efter vi i går her på sitet kunne bringe en artikel om, hvordan døren stod vidt åben til en uktypteret FTP-server hos CSC, hvor blandt andet kildekoden til Polsag lå frit fremme.

»Det er dybt kritisabelt. Det koster altså ikke meget at sætte en Linux-maskine op, som kan kryptere FTP’en. Det skal der bare være styr på.«

Sikkerhedshullet blev i 2011 opdaget af Anders Jensen, der i sin tid var medarbejder i en virksomhed, der har adgang til CPR-udtræk fra CSC, og selvom han straks alarmerede CSC, måtte der gå et år og endnu en henvendelse, før hullet blev lukket.

Læs også: Sikkerhedshul gav adgang til CSC-server: 'Jeg kunne blandt andet se kildekode til Polsag'

Poul-Henning Kamp, der ligesom Version2 har været i kontakt med Anders Jensen mener ikke, at der er nogen undskyldninger for, at CSC ikke havde krypteret sin FTP-server.

Ifølge Poul-Henning Kamp giver det indtryk af en virksomhed, der ikke tager sikkerheden seriøst. Ikke mindst fordi alt tyder på, at CSC ikke reagerede på Anders Jensens advarsler, før der var gået op mod et år.

Samme indtryk fik en kollega til Anders Jensen, der ved et tilfælde havnede i CSC-serveren.

»Da Anders kontaktede CSC, blev han sendt rundt mellem flere forskellige medarbejdere. De lovede til sidst at lukke hullet, men det virkede som om, de ikke tog det alvorligt,« siger Mads Thomsen, der i sin tid sad på kontor med Anders Jensen. Ingen af de to arbejder længere i den pågældende virksomhed.

Under alle omstændigheder er det dybt kritisabelt, at CSC ikke reagerer på henvendelsen med det samme og får hullet lukket, mener Poul-Henning Kamp. Det glæder ham dog, at der endelig er én, der tør at stå frem med en sag som denne.

»Jeg har hørt om flere af den slags sager blandt folk derude, men denne er unik, fordi der endelig er én, der tør stå frem. Nu kan vi bare håbe, at Datatilsynet reagerer. Noget tyder på, at der er en generel, ligegyldig holdning hos CSC, som ikke mener, at der skal komme nogen og banke på deres dør. De kører løbet selv,« siger han

Også internetaktivisten Torben Andersen fik i 2013 adgang til flere ubeskyttede FTP-servere hos CSC ved hjælp af det gratis værktøj ShodanHQ - uden at anvende hverken brugernavn eller password. Der lå data som alle i princippet kunne få adgang til.

Læs også: Aktivist finder ubeskyttede FTP-servere hos CSC

På reddit.com skriver han tirsdag i kølvandet på den nye sag, at han ligeledes forsøgte at trænge i gennem til CSC for at fortælle om de pivåbne servere, han havde fundet.

»Men jeg blev kastet rundt i deres system i flere timer. Det var som om, at de ikke fattede alvoren,« skriver han.

Ifølge Anders Jensen har CSC sidenhen ændret sit system, så det er bedre beskyttet.

Også i dag har Version2 forgæves forsøgt at få kommentarer fra CSC - både i forhold til denne sag og for at høre, hvorvidt de efterfølgende har rettet op på sikkerheden.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (29)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Thomas Hedberg

Sikkerheds bristen med at root var konfigureret forkert har ikke det fjerneste at gøre med om FTP protokollen er krypteret eller ej og interne servere skal ikke nødvendigvis have kryptering slået til.

Sikkerheds tilvalg (som f.eks kryptering) bør vælges udfra en risiko vurdering som tager udgangspunkt i hvad man ønsker at beskytte og hvad det er værd for en udfra nogle forskellige parametre.

Man kan så diskutere om CSC vurderer rigtigt, når de vælger relativt få og simple kontroller til at beskytte source koden fra f.eks det fejlslagne polsag.

Søren Larsen

Rodes der ikke rimeligt meget rundt i begreberne her? Sagen var vel at man som bruger af CSC's systemer havde adgang til mere end sine egne data.
Hvis det havde været på plads og selve filtransporten iøvrigt er krypteret, er der vel ingen grund til at kryptere hele serveren.
Spørgsmålet er om transporten var krypteret eller om man skal tage de mange kommentarer om FTP (ikke SFTP) for gode varer - for så er det jo helt ubegribeligt...

Poul-Henning Kamp Blogger

interne servere skal ikke nødvendigvis have kryptering slået til.

Det var ikke en "intern server", den blev brugt til dataoverførsel med udefra kommende.

Den eneste reelle sikkerhed var IP ACL, hvis login+password blev overført i klartekst.

Der var så vidt mine kilder heller ikke nogen politik om at passwords nogensinde skulle eller ville blive ændret og rettelser i IP ACL blev foretaget uden nogen formel verifikation hvis "man ringede til den rette person og lød troværdig."

Kristian Rastrup

Hvorfor har man en intern server med al kildekoden, hvor man sætter en ukrypteret FTP-server op på og giver verden adgang til den (Vi ignorerer lige at FTP serveren var sat forkert op, selv om det var her hele risikoen i setupet lå)? Hvad har man af (fornuftig) begrundelse for at lave det setup?

Poul-Henning Kamp Blogger

Rodes der ikke rimeligt meget rundt i begreberne her? Sagen var vel at man som bruger af CSC's systemer havde adgang til mere end sine egne data.

Nej, der er faktisk en lang række af problemer.

  1. Plaintext overførsel af brugernavn/password

  2. Ingen udskiftning af passwords over tid

  3. Lemfældig vedligehold af IP ACL

  4. Ingen kryptering af personfølsomme data

  5. Alle har adgang til alt på serveren

  6. Ingen klar placering af ansvaret for sikkerheden

  7. Ingen procedure for håndtering på udefra kommende advarsel om sikkerhedsproblem

  8. Ingen paper-trail på udefra kommende advarsel om sikkerhedsproblem

  9. Ingen opfølgning på udefra kommende advarsel om sikkerhedsproblem

Carsten Gehling

Jeg forstår ikke at sikkerhed på en *nix boks skulle være et TILVALG.

Når jeg sætter en ny boks op, så bliver der installeret SSH som udgangspunkt. Og ikke andet. Skal en bruger have "ftp-adgang", så opretter jeg en bruger til dem og lærer dem om hvordan sFTP fungerer (hvilket udmærkede klienter som Filezilla fint håndterer). What's the fuckin' problem?

Christian Nobel

Hvorfor har man en intern server med al kildekoden, hvor man sætter en ukrypteret FTP-server op på og giver verden adgang til den (Vi ignorerer lige at FTP serveren var sat forkert op, selv om det var her hele risikoen i setupet lå)? Hvad har man af (fornuftig) begrundelse for at lave det setup?

Jeg undrer mig også såre.

Der er da vel ikke kun en server hos CSC, så hvorfor i alverden ligger der overhovedet kildekode og hvad ved jeg på en næsten åben FTP server?

Som jeg ser det, så kan de sådan set godt have en (åben) FTP server stående, på hvilken der er mulighed for at kunne hente (stort set ufarlige, hvis der ikke lige ved et uheld er proppet CPR numre med) ting som Robinsonlisten (formoder det er en kommasepareret fil?), MEN denne FTP server skal bare ikke have noget med resten af CSC' verden at gøre.

Så når Robinsonlisten generes hver måned (åbenbart fra grunden - sic), så bør det da være som et SQL udtræk fra en ellers super sikker boks, som hælder udtrækket over i FTP serveren.

Noget med ikke at lægge alle æg i en kurv.

Frithiof Andreas Jensen

RACF (Resource Access Control Facility) -

Der findes ingen billige sysops "på markedet" som kan finde ud af at konfigurere RACF korrekt og/eller hver gang nogen skal have ändret noget i opsätningen kräver det fra gammel tid en räkke formelle workflows, godkendelse(r), review, test og backup/rollback.

Med til alle disse formalia hörer Sporbarhed. Dette kolliderer med "Uvidenhedsprincippet", det forhold at en leder kan få hele lönnen uden ansvaret så länge han/hun " ... ikke var klar over ..." eller " ... ikke kan forestille sig ...", det bliver svärt at få de nödvendige godkendelser til RACF-ändringer, det hele sander til i proces & bureaukrati og kunderne klager naturligvis.

Derfor er det meget nemmere at konfigurere EEN "intern" konto med maksimal adgang og sätte et job op til at dumpe hele svineriet på "en Linux box i et kosteskab som man kan betale et par studenter for at vedligeholde" - eller en lille VM hos vores allierede i Pakistan.

Problemet er löst og alle er glade, også NSA og BND.

Poul-Henning Kamp Blogger

What's the fuckin' problem?

Formodentlig at de kører en mainframe.

Da TCP/IP blev introduceret på IBMs mainframes var det mildest talt ikke på nogen særlig struktureret måde og tilgangen til sikkerheden var den klassiske mainframes "perimeter defence", dvs. man stolede på at alle der var kommet så langt var blevet screenet som "insidere" og derfor "trustworthy".

Det skal siges at der i IBMs dokumentation stod nogle lidt vage advarsler om at stort set alle de sædvanlige mekanismer til dette ikke fandt anvendelse på TCP/IP.

Nogle af de første implementeringer havde noget der bedst kan beskrives som deres egen "UNIX-style" password fil, helt uden om den normale brugeradministartion og i hvertfald i en periode kunne denne facilitet stadig supplere den normale brugeradministration for TCP/IP formål.

Men så længe man kun brugte TN3270 eller FTP internt i organisationen på lukkede netværk var det dog ikke væsentligt mere lemfældigt end andre aspekter af sikkerheden (MAC spoofing på TR osv.)

Balladen opstår i det øjeblik man begynder at åbne for adgang udefra.

Traditionelt har dataoverførsel ind og ud af mainframes sket med magnetbånd.

At konfigurere en forbindelse til filoverførsel mellem to mainframes var nærmest et mareridt af rang (se: LU6.2) og de fleste henfaldt til løsninger hvor en OS/2 maskine legede 2780/3780 BSC/RJE terminal imod de to mainframes på skift via dial-up forbindelser. Enten manuelt eller med et lille batch-script. På sædvanlig mainframe maner var evt. passwords hardkodede og blev aldrig ændret.

Med FTP og internet blev det pludselig meget nemmere at flytte filer direkte og alt for mange installationer begyndte at gøre det, uden overhovedet at fatte hvad de havde gang i rent sikkerhedsmæssigt.

Nogen af dem, herunder CSC, har åbenbart stadig ikke fattet det.

Det skal retfærdigvis siges at TCP/IP på mainframes er blevet forbedret meget, men når man nu engang har noget der kører og der er dusinvis af eksterne parter man skal have "opgraderet" hvis man laver om på noget, så bliver der ikke lavet om på noget bare fordi det ikke er så sikkert som det kunne være.

Der har jo ikke været nogen problemer og IP# og brugernavn+password er jo hemmeligt, ikke sandt ?

CPR registeret har historisk været ret langt fremme i skoene med sikkerhed, men hvis du kigger på deres "FTP checkliste" https://cpr.dk/migrering-af-cpr-systemet/tjeklister/ftp/ får du et indtryk af det faglige niveau hos deres "kunder".

Steen Thomassen

Selv på et internt netværk, der ville jeg til enhver tid bruge SSH i stedet. Brugen af FTP betyder vel også, at man så mangler en eller anden form for remote management adgang - er det så TELNET?


FTP bruges mange gange, når man udveksler data med eksterne parter, da de let at komme igang med og der findes masse af klienter. Og på serversiden har jeg arbejdet med software, hvor kunne have særskilt logins uafhængig af operativsystems konti - det kræver ssh. Det er et must når man har mange hunderede brugere, som man ikke ønsker skal have operativsystemkonti.

Poul-Henning Kamp Blogger
critter phk> ftp oes-cs.dk  
Connected to oes-cs.dk.  
220-FTPSERVE IBM VM Level 530 at WWW.OES-CS.DK, 10:53:53 DST THURSDAY 2014-07-10  
220 Connection will close if idle for more than 15 minutes.  
Name (oes-cs.dk:phk): ftp  
331 Send password please.  
Password:   
530 Login attempt by 'FTP' rejected  
ftp: Login failed  
ftp> 

Hat-tip til @kramse

Thomas Hedberg

@Poul-Henning Kamp

"Det var ikke en "intern server", den blev brugt til dataoverførsel med udefra kommende"

Jeg kommenterer ikke på om denne server aktuelt er en intern server eller ej. Det står klart at den er tilgængelig udefra og ikke kan betragtes som intern.

Jeg kommenterer på at artiklen er rodet, blander nogle problem stillinger sammen og den starter med en generel anbefaling jeg ikke er enig i.

»En intern server bør være krypteret. Især hvis den ligger inde med følsomme oplysninger,«

Sætningen er for det første upræcis - for hvad er en krypteret server?

  1. Er det en full disk encryption af alle diske?
  2. Er det en kryptering af udvalgte data på serveren og på applikations eller OS niveau?
  3. En krypteret protokol når der overføres data til/fra serveren?
  4. En kombination en eller flere af ovenstående.

Derudover er jeg grundlæggende uenig i at man altid skal køre alle kontroller i spil på alle servere. De fleste af os er normalt nød til at prioritere resourcer som tid og penge for at få mest muligt ud af dem. Derfor skal servere og data beskyttes efter den risiko de udgør og alle sikkerheds kontroller behøver ikke hovedløst at blive implementeret overalt. At nogle kontroller er så basale, simple og/eller billige at de altid bør anvendes er så noget andet, men jeg mener desværre ikke administrationen omkring krypterings certifikater m.m. er der endnu.

Jeg undlader at kommentere på mangler hos CSC, da jeg ikke på nuværende tidspunkt kender til CSC's interne procedurer, systemer eller de data de hoster på dem. At noget lader til at være grundliggende galt står dog temmeligt klart og det er en interessant liste du bragte i et andet indlæg.

Helge Svendsen

Det er et must når man har mange hunderede brugere, som man ikke ønsker skal have operativsystemkonti.

Så skal du jo have brugerne i en anden bruger tabel? Een til FTP serveren. Jeg kan ikke se forskellen ift SSH, du skal naturligvis bruge en shell, der kun giver adgang til det, du ønsker.

Der findes adskillige, der begrænser til eks. SCP. Evt kombineret med at køre i rette jail eks.

Henrik Kramshøj Blogger

FTP bruges mange gange, når man udveksler data med eksterne parter, da de let at komme igang med og der findes masse af klienter. Og på serversiden har jeg arbejdet med software, hvor kunne have særskilt logins uafhængig af operativsystems konti - det kræver ssh. Det er et must når man har mange hunderede brugere, som man ikke ønsker skal have operativsystemkonti.

Stort suk, og så igen et suk

FTP er død FFS! Det er ikke rimeligt at bruge en så gammel ukrypteret protokol som overfører kodeord i klar tekst.

Du kan fint styre dine ønsker med SSH, been there, done that. Keywords: SFTP only, RADIUS, LDAP, ForceCommand, Match Groups

Du kan evt starte fra det eksempel som altid er med i sshd_config

Example of overriding settings on a per-user basis
Match User anoncvs
X11Forwarding no
AllowTcpForwarding no
ForceCommand cvs server

Når så du har valgt SFTP/SSH til protokol så bemærk at MANGE FTP klienter idag, eksempelvis FileZilla understøtter SSH og har gjort det i mange år.

Der er således ingen undskyldning for at være en sløset IT-mand der accepterer FTP i 2014! Hvis du insisterer på at der er rimelige argumenter vil jeg shame dig - ligesom jeg gerne gør med CSC.

BTW Det ligner også at CSC har en SunOS Telnet stående åben ud til internet, det er heller ikke iorden! Samme host har ligeledes OpenSSH 4.3 - 4.3?! Altså WTF er det for en opførsel fra et firma der skulle være ansvarlige for vores allesammens data.

Steen Thomassen

@kramshøj
Hvis man har mange eksterne brugere, som kun skal udveksle data en gang imellem skal man overveje risiko over for forretning og de administrative processer. Og om det er data som kræver beskyttelse. Og hvis det er person-data er kryptering et must.

Jeg synes at ssh godt - men ikke til alt. Den er god til kommunikation imellem UNIX/Linux maskiner og for andre som arbejde på miljøet. Men administration af mange konti på operativsystemniveau, som skal oprettes, ændres, flyttes og slettes. I CSC’s tilfælde 600 eksterne som burde have haft egen konto… det kræver nogle værktøjer, som kan arbejde med de administrative systemer bagved, samt support ikke mindst! Men det godt at der er kommet flere klienter, som kan håndteres ssh… (jeg følger ikke området for klienter for tiden)

Har nogen finde en reference, hvor almindelige brugergruppe (som ikke er programmører og systemadministratorer) bruger ssh til dataudveksling?

Mit alternativ til en ftp-server, er at bruge https (så man får kryptering). Og det vil også være mit førstevalg, hvis jeg skal designe et nyt system i dag. Det er nemmere at pakke det ind i et administrationssystem, som kan håndteres af kontorassistenter e.lign., som ikke behøver andet end almindelige brugerrettigheder.

@Nikolaj Hansen
Ja - det krævede en ekstra fil til brugerkonti og password til ftp-serveren, som ikke havde operativsystemkonti… men det var gjorde de administrative processer lettere at håndterer. Og der findes også moduler, så de kan lægges ind i en sql-database.

Henrik Kramshøj Blogger

@kramshøj
Hvis man har mange eksterne brugere, som kun skal udveksle data en gang imellem skal man overveje risiko over for forretning og de administrative processer. Og om det er data som kræver beskyttelse. Og hvis det er person-data er kryptering et must.

Hvis du giver password til brugere er det vel person-data - ellers er der ingen grund til at der er individuelle passwords, og et shared password som Robinsonlistens ... suk

FTP sender i klartekst, og hvis du sender password i klar tekst har du sendt person-data i klar tekst, hvad er det svære at forstå? Du har ingen sikkerhed for at den som logger ind er den person som har fået udleveret kodeordet og din sporbarhed er væk sammen med den ringe sikkerhed du havde fra starten.

Koblet med at mange bruger samme passwords til andre services og så har du den komplette kompromitering af enten den ene ende eller begge ender, og måske også folks private liv på internet.

Tænk et sekund på hvad der ville ske hvis man tog kodeordslisten fra One.com (stor websideudbyder i DK, meget populær grundet 1kr/md hosting) og afprøvede de brugernavne/kodeord på VPN'er og logins generelt i DK,wauw - et helt land ville være kompromitteret og 1000vis af servere i mange mange organisationer.

Det er useriøst og uprofessionelt at bruge FTP til overførsel af data med kodeord! Både hos webhosting og andre, men specielt hos et firma som CSC (eller KMD for den sags skyld).

Mht. HTTPS som erstatning for SSH, be my guest - men hvis du fortsat taler FOR FTP som protokol håber jeg ALDRIG aldrig aldrig du kommer i nærheden af mine data!

Helge Svendsen

Ja - det krævede en ekstra fil til brugerkonti og password til ftp-serveren, som ikke havde operativsystemkonti… men det var gjorde de administrative processer lettere at håndterer. Og der findes også moduler, så de kan lægges ind i en sql-database.

Jeg kender fint de forskellige værktøjer, og kan overhovedet ikke se nogen grund til FTP. Som skrevet ovenfor, så er valget af protokol jo transperent for brugere af eks en client som FileZilla. Hvis du kører din SSHD i et jail, (det er altid en god ide, når noget skal på nettet), så har den automatisk sin egen bruger tabel. Du behøver, som skrevet, heller ikke at give fuld konto adgang i dit jail, hvis du eks. bruger scponly som shell til rette bruger konti.

Mht. HTTPS som erstatning for SSH, be my guest - men hvis du fortsat taler FOR FTP som protokol håber jeg ALDRIG aldrig aldrig du kommer i nærheden af mine data!

Klog af skade skulle man synes CSC også burde have lært det på nuværende tidspunkt.

Steen Thomassen

@kramshøj

Mht. HTTPS som erstatning for SSH, be my guest - men hvis du fortsat taler FOR FTP som protokol håber jeg ALDRIG aldrig aldrig du kommer i nærheden af mine data!


Organisationen skal sige ja til det, hvis jeg skal oprette en ftp-server til driftsbrug. (og skal en god grund til det.) Men din virksomhed ikke har brugt for det og ønsker det ikke. Og de data, jeg arbejder med, er fuld offentlig tilgængelige.. husk - sikkerhed tager udgangspunkt i en risikovurdering! Hvis det er offentlig tilgængelige data, gør ikke noget, om det transporteres via en ikke krypteret forbindelse. Det er kun password, som kunne være kritisk, hvis, som du skriver, bliver genbrugt andre steder imod god praksis.

Jeg har tjekket nogle få webhoteller - de bruger status ftp som default, men nogle få supporter også ftps eller sftp. Gæt - de fleste bruger stadig ftp... det vil tage mange år før ftp er blevet afviklet...

Og så håber at webhoteler, som den du nævnte, bruger hash'et passwords og ikke har dem i klartekst.

Jeg er enig at til robinsonlistens burde have individuel brugerlogin.. fælles login til 600 - ak!

Sune Marcher

Jeg synes at ssh godt - men ikke til alt. Den er god til kommunikation imellem UNIX/Linux maskiner og for andre som arbejde på miljøet. Men administration af mange konti på operativsystemniveau, som skal oprettes, ændres, flyttes og slettes.


Du behøver jo ikkke en OS-konto per bruger, fordi SSH er involveret - det er ret trivielt at sætte op.

(Hvor mange brugere er det GitHub har på SSH-brugeren git@github.com?)

Du kan koble en pubkey op på en arbitrær "shell", med arbitrære kommandolinier - og du behøver jo ikke nødvendigvis at have SSHD til at serve, bare fordi protokollen er SSH (se fx. Atlassians Stash til Git-styring).

Henrik Kramshøj Blogger

Så må det være trivielt at fortælle hvordan et PoC kan sættes op... jeg vil gerne prøve det af.

Vil du have os til at fortælle dig hvordan? Så du vil gerne prøve men ikke nok til at bruge 5 min til at google det selv?

Jeg håber seriøst jeg misforstår dig, og i så fald undskyld - men hvis du forventer at blive madet med en ske ... jeg tror min ske er til vask, sorry. Hvis ikke respekten for andres passwords er nok til at IT-folk bruger google 5 min og derefter sætter sig ind i basale teknologier som er grundlaget for vores brug af internet mellem organisationer på internet - så har vi fandme et stort problem som IT-fag! suk.

Steen Thomassen

Vil du have os til at fortælle dig hvordan? Så du vil gerne prøve men ikke nok til at bruge 5 min til at google det selv?


Sune skrev at det var trivielt at sætte op… Og du skriver at det er let at google sig til det. Men det kræver lidt baggrundsviden, som man vel ikke kan forvente alle kan, andet end hvis man har arbejdet på et miljø, hvor det er relevant. Jeg selv skulle lige grave i hukommelsen, hvordan man håndtere det. Men rart at få det genopfrisket.

Log ind eller Opret konto for at kommentere