Forestil dig, at din laptop bliver befængt med malware.
Forestil dig så, at malwaren sidder i maskinens firmware, altså computerens indbyggede software. Denne software kører før et styresystem som Windows eller Linux overhovedet bliver indlæst.
Når systemet er kompromitteret på firmware-niveau, forsvinder den ondsindede kode ikke, blot fordi harddisken bliver formateret og/eller styresystemet geninstalleret.
En træls tanke, og et af de emner, som CEO ved Invisible Things Lab Joanna Rutkowska berørte under sit indlæg på Black Hat Europe it-sikkerhedskonferencen, der fandt sted i London tidligere på måneden.
Titlen for indlægget var 'Security Through Distrusting' eller på dansk: sikkerhed gennem mistillid.
»Konceptet er at minimere mængden af ting, som vi stoler på. I den virkelige verden tror jeg ikke, at vi kan have perfekt kode eller ting, der opfører sig, som vi ønsker,« fortæller Joanna Rutkowska i et opfølgende interview med Version2.
Når firmwaren er ondsindet
Under et andet indlæg på Black Hat Europe-konferencen fortalte Mark Ermolov og Maxim Goryachy fra Positive Technologies om en sårbarhed, der har fundet i Intel Management Engine (ME), og som i princippet gør det muligt netop at kompromittere firmware i en computer.
Joanna Rutkowska fremhæver denne form for kompromittering som et eksempel på, hvorfor 'Security Through Distrusting'-tankegangen giver mening. Altså lad i udgangspunktet være med at stole på firmwaren i eksempelvis en laptop.
»Problemet er, at infektionen består, selvom du geninstallerer operativsystemet. Og det er et stort problem,« siger Rutkowska.
Og sådan som laptops er skruet sammen i dag er det vanskelig komme problemet til livs, når firmware kører i form af mere eller mindre ukendt kode på chips inde i selve computeren.
Dels er firmwaren ikke nødvendigvis lige til at opdatere. Og derudover vil et forsøg på at opdatere firmwaren i udgangspunktet foregå via software, der kører på computeren med den kompromitterede firmware. Og så er processen, der læser og opdaterer firmwaren heller ikke til at stole på.
En stick
For at løse problemet har Joanna Rutkowska tidligere foreslået en noget anderledes tilgang til firmware på for eksempel en laptop.
Tilgangen går ud på at gøre selve laptoppen stateless, og så flytte al den firmware, der kører på chips inde i maskinen ud på en enhed, der kan fjernes fra systemet. Joanna omtaler det som en 'stick'. Sådan en kunne minde om alt fra en USB-nøgle over et sim-kort til et SD-kort. Pointen er, at firmwaren kører fra en ekstern enhed, der let kan fjernes fra systemet.
»Sådan en enhed kunne sandsynligvis fremstilles af flere leverandører. Det ville være simpelt og let at fremstille enheden, modsat bundkort, som er ekstremt komplekse og vanskelige at fremstille,« siger Joanna Rutkowska.
Grundtanken med at flytte al software ud af chips inde i maskinen og over på en ekstern enhed er, at hvis softwaren på den eksterne enhed bliver kompromitteret eller formodes at være blevet det, så kan integriteten kontrolleres og stick'en re-installeres (eller smides ud).
Og da der er tale om en ekstern enhed, behøver integritets-tjek og geninstallation i udgangspunktet ikke foregå via systemet med den kompromitterede firmware. I stedet kan 'stick'en sættes i en simpel læser, hvorpå eksempelvis formateringen kunne foregå.
Altså på samme måde, som et SD-kort kan smides i en læser, hvorefter der kan lægges ny data på kortet.
I forhold til SD-kort, så fremhæver Joanna Rutkowska, at disse kort kan have en fysisk kontakt, der kan bruges til at skrivebeskytte kortet med. På lignende vis nævner hun, at det kunne være muligt mekanisk at gøre firmware-stick'en skrivebeskyttet for helt at forhindre, at malware kan skrives til enheden.
Et scenarie, hvor den eksterne firmware kunne være handy, kunne være en medarbejder, der rejser til et andet land. Vedkommendes laptop bliver under rejsen tilbageholdt i tolden, for så at blive udleveret en time senere. Hvis ellers medarbejderen eller dennes virksomhed er interessant nok, kan computerens firmware nu være blevet inficeret med malware til overvågning eller andet.
I stedet for at smide computeren i skraldespanden vil det jævnfør stick’en i princippet være nok at sætte en stick med frisk firmware i maskinen (og genetablere styresystemet).
Inden det kommer så vidt vil det som udgangspunkt også være relativt let at teste, om den software, der ligger på firmware-sticken, er blevet ændret i forhold til den officielle firmware, der måske bliver rullet ud fra virksomhedens it-afdeling.
Nok ikke lige om hjørnet
Det er to år siden, Joanna Rutkowska første gang luftede tanken om firmware på en stick ved en anden konference. Og siden er firmware-on-a-stick ikke blevet udbredt. Og det virker heller ikke som om, det er på vej til at blive det.
»Det er vel fordi, marginerne for at producere bundkort disse dage er meget lave. Jeg ved det ikke. Hvis jeg var en OEM (Original equipment manufacturer, eksempelvis en laptop-producent, red.), så ville jeg gøre dette. Det er jeg ikke.«
Nu hvor Intel, takket være folkene fra Positive Technologies arbejde, har fået fornyet fokus på sikkerheden i virksomhedens firmware, kan det være, en angriber hellere vil gå en anden vej.
Når ondsindet kode bliver blåstemplet
En potentielt mere simpelt og nok ikke mindre effektiv vej at gå - set med en angribers øjne - kunne være at inficere de trustede software-produkter, som brugere og it-afdelinger frivilligt installerer på computere. Eksempelvis en browser eller et program til at læse PDF-filer med.
Så næste gang klienten - mere eller mindre automatiseret - installerer en browser-opdatering, så ryger der en gang malware med ind i systemet også.
Joanna Rutkowska ridser angrebsvinklen op som et andet eksempel på, hvor Security Through Distrusting kunne give mening. Altså lad være med at stol på binær software, selvom den kommer fra en leverandør, du i udgangspunktet har tillid til.
Og hvorfor så ikke?
Jo, forestil dig, at systemerne hos software-leverandøren er blevet kompromitteret, så malware bliver skudt ind inden build. Altså processen, hvor kildekode bliver omdannet til eksekverbar binær-kode.
Resultatet er, at selvom kildekoden, som et menneske kan læse, ser fin ud, så er den binære-kode - som bliver læst af computeren - blevet ond.
Når build-processen nu er færdig, signerer software-leverandøren den binære kode med sine private nøgle, som så bliver rullet ud til alverdens systemer. Og da koden, som nu indeholder malware, har fået det officielle blå stempel i form af signaturen fra software-leverandøren, så er der i udgangspunktet ingen grund til at mistænke, noget er galt.
Flere build-setups
En løsning på dette problem kan ifølge Joanna Rutkowska være, at software-leverandøren har flere build-setups. Eksempelvis et build-setup i USA, et i Europa og et i Asien.
I udgangspunktet vil de enkelte build-lokationer være i stand til at generere den samme binære kode, forudsat samme kildekode er anvendt til at builde ud fra.
Herefter kan de enkelte builds så sammenlignes på tværs af lokationer. Og hvis ellers alt er, som det skal være, kan en binær build signeres af de enkelte lokationers unikke, private nøgle.
»Alle, som builder fra den samme kildekode, vil få den samme binary, hvilket betyder, folk kan bevidne, at denne binary - byte for byte - kommer præcist fra denne kildekode, og så kan de alle signere den,« fortæller Joanna Rutkowska.
Idéen er, at nu kan brugeren verificere, at den binære fil, der er ved at blive rullet ud på vedkommendes system, er signeret med eksempelvis tre forskellige build-lokationers private nøgle. Altså en blåstempling af den binære kode i forhold til kildekoden fra tre forskellige entiteter.
Sådan et setup er stadig sårbart. Men nu skal en angriber, der før kunne nøjes med at kompromittere et build-setup, kompromittere tre lokationer. Og det er - alt andet lige - mere besværligt.
En udfordring
Det med builds flere steder er dog også forbundet med en teknisk udfordring. Det er nemlig ikke nødvendigvis lige til at generere identiske binære filer, som er forudsætningen for, at tilgangen med builds på flere lokationer, fungerer.
Forklaringen er, at selvom build-hardwaren er ens, så er der ifølge Joanna Rutkowska stadig en række parametre, der kan bevirke, at den binære fil bliver en lille smule anderledes, end en anden binær fil, selvom kildekode-udgangspunktet er identisk
»Det er på grund af timestamps, som påvirker de deraf følgende binaries, det er antallet af tråde, der bliver brugt, når man kører build-processen. Der er en række ting.«
Der er dog hjælp til dette problem. Joanna Rutkowska fremhæver Projektet Reproducible, som netop går ud på at løse udfordringen med at generere identiske binære filer ud fra identisk kildekode til livs.
Det kan du læse mere om her https://reproducible-builds.org/
