Artiklen blev oprindeligt publiceret på Version2 og er skrevet af Frederik Denning, der er Chef for Drift og DevOps hos Magenta.
I maj måned opstod et sikkerhedshul i open source DevOps softwaren Salt, som kompromitterede en lang række servere verden over. Mange servere blev sat til at mine bitcoins, men hackere kunne lige så vel have udsat virksomhederne for Ransomware eller totale wipes af databaser.
Da sikkerhedshullet relaterede til den mest centrale server i Salt-teknologien, nemlig Salt Master serveren, gav sikkerhedshullet effektivt adgang til root access på alle servere (kaldet minions i Salt) konfigureret af Salt.
I forlængelse af dette bragte Version2 en artikel med overskriften ‘Open source blottede sikkerhedshul i tusindvis af servere‘, som indikerer at open source software skulle være mere usikkert end proprietært software. Netop denne opfattelse møder vi med jævne mellemrum i vores arbejde med open source software hos Magenta.
Seneste eksempel på dette kommer til udtryk hos danske sundhedsmyndigheder, trods anbefalinger fra EU-kommissionens eHealth-netværk, som skitseret i en anden nylig artikel bragt af version2.
Opfattelsen bunder som regel i idéen om, at adgang til kildekode skulle gøre et produkt nemmere at hacke. Hackerangreb baseres dog sjældent på kendskab til kildekode eller systemer, men på en omgåelse af systemets almindelige protokoller, f.eks. gennem buffer overflows.
Adgang til kildekoden kan måske nok afsløre de mest iøjnefaldende og trivielle sikkerhedshuller, men kun hvis de faktisk findes – og kun hvis resten af infrastrukturen ikke er sikret ordentligt. Åben kildekode styrker mulighederne for at løse sikkerhedshuller proaktivt, og gør dermed også sikkerhedshuller hurtigere at fikse.
I stedet for et lukket udviklingsteam har man et globalt community på flere tusinde mennesker, der proaktivt vedligeholder softwaren og holder øje mod potentielle farer. I stedet for at have et eksternt sikkerhedsbureau til at foretage vurderingen, kan man lade de tusindvis af dygtige
udviklere, der skal benytte softwaren have kritiske øjne på. Det ene udelukker i øvrigt ikke det andet.
Eksemplet med sikkerhedshullet i Salt i maj måned var ikke kritisk, fordi Salt er open source software, men fordi det var en helt central del af infrastrukturen hos de virksomheder der benytter Salt.
Version2’s artikel om forløbet påpeger helt korrekt at »da Salt er open source-software, var patchen nemlig spækket med oplysninger om problemet.« I dette tilfælde benyttede hackere informationer fra patchen som udgangspunkt for at bryde ind i systemet, men havde hacket været udviklet på baggrund af en reverse engineered patch til proprietær software, var sikkerhedshullet formentlig fløjet helt under radaren hos de mange kunder, der burde opgradere hurtigst muligt.
Der er mange forskellige måder at udgive patches til open source software, fx ved at release en patch som en binær fil og først efter nogle uger udgive kildekoden til den. SaltStack, virksomheden bag Salt, er nok blevet en hel del klogere på, hvordan man bør håndtere kritiske sikkerhedshuller efter denne incident, men de fejltrin, de begik, kunne de ligeså vel have begået, hvis deres software havde været proprietær.
Sikkerhed i dybden
Hos Magenta har vi drevet open source virksomhed i 21 år og udviklet alt fra websider til store infrastrukturprojekter som open source. På samme måde drives vores egen infrastruktur af open source projekter.
Salt er en central del af vores implementering af den DevOps filosofi, der sikrer høj kvalitet, hurtige releases og vidensdeling, og derfor var vi også i højeste alarmberedskab, da vi så hvor hårdt en række andre virksomheder var blevet ramt.
Vi kunne se i vores IP-logs, at vores servere også var forsøgt angrebet, men uden held: Vi havde patchet sikkerhedshullet inden de aktive angreb startede, og efter en grundig undersøgelse af evt. yderligere sårbarheder på de relevante servere, konkluderede vi, at vi havde handlet proaktivt og dermed sikret vores infrastruktur i tide.
Naturligvis har det været en sund anledning til at sikre vores infrastruktur endnu bedre.
Det er vigtigt at gøre sig klart, at alt software er sårbart. Proprietær software har også sikkerhedshuller, patches bliver reverse engineered, og infrastruktur kompromitteres.
Uanset om man bruger open source eller proprietære løsninger, skal man sikre sin infrastruktur bag flere lag af sikkerhed. På den måde sikrer man, at selvom ét link går i stykker, så holder kæden. Det skal man gøre uagtet om man baserer sin infrastruktur på open source-løsninger eller på proprietær software.
Tiltag som overvågning, eksterne sikkerhedsscanninger, penetrationstests, netværkssikkerhed og -afgrænsninger er eksempler på tiltag, man kan tage for proaktivt at sikre sin software og infrastruktur. Når man som de danske sundhedsmyndigheder ønsker at indhente følsom data på brugere af app’en Smittestop, så er det helt naturligt at koden skal være tilgængelig som open source.
At sende app’en gennem et sikkerhedstjek giver ikke brugerne af app’en en forståelse for, hvordan deres data håndteres. Det giver ikke civilsamfundet indsigt i, hvilke mekanismer der rører sig under overfladen. Og hvis det eksterne sikkerhedstjek viser, at app’en er fuldkommen sikker, hvad er så egentlig risikoen ved at gøre koden tilgængelig som open source?
