Om Node.js, Electron och den nya uppbyggnaden av våra skrivbordsapplikationer
I den här bloggen tänkte jag översiktligt diskutera ett gemensamt ramverk som många populära skrivbordsapplikationer har börjat använda de senaste åren, och varför vi borde vara lite skeptiska till dess förekomst från en säkerhetssynpunkt.
Viljan att köra JavaScript överallt: Vad är Node.js och Electron?
Under de senaste åren har användandet av JavaScript exploderat. Framförallt har JavaScript, som tidigare framförallt användes i webbläsare, gjort sitt intåg på serversidan. Den mest framträdande anledningen till detta är Node.js. Genom att tillämpa samma JavaScript motor som används i Google Chrome (samt open source varianten Chromium) kombinerat med länkandet till C och C++ systembibliotek, möjliggör Node.js omfattande kontroll av server-maskiner. Med det kan Node.js ersätta exempelvis PHP som drivkraft för dynamiska innehåll på serversidan. Resultatet blir en harmonisering av designen mellan server- och klient-sidan där samma programmeringsspråk kan användas till båda.
Det är inte Node.js ensamt som står för den avgörande ökningen av JavaScript, utan Electron. Electron är ett ramverk som möjliggör byggandet av plattformsoberoende skrivbordsapplikationer. Electron används i många populära program så som Signal, Slack och Skype. Dess back-end består av Node.js och dess front-end av Chromium. Därav består varje Electron-applikation av en egen webbläsare kopplad till en server körandes Node.js, allt på samma maskin. Från ett utvecklarperspektiv är Electron-ramverket ytterst attraktivt eftersom tidigare web-applikationskod direkt kan återanvändas till skrivbordsapplikationen utan större modifikationer. Dessutom kommer det resulterade programmet att fungera i princip alla operativsystem. Dock finns det anledning till att inte vara hejdlöst optimistisk inför den ökande förekomsten av Electron baserade applikationer.
Vad är nackdelarna med Electron:s uppbyggnad?
Bortsett från prestandabekymmer så torde det vara klart att användande av Electron kan innebära en förhöjd säkerhetsrisk jämfört med ”traditionella” skrivbordsapplikationer. I princip är Electron inget annat än en en webbläsare, med potentiellt större befogenheter en vad en vanlig någonsin har (i och med Node.js integration). De mest framträdande tänkbara risker relaterat till användandet av Electron kan summeras som:
- Utökad attackyta i och med Electrons beståndsdelar: Node.js, Chromium och JavaScript (biblioteket).
- Öppnandet för web-applikationsattacker i skrivbordsmiljö, så som cross-side-scripting och spoofing.
- Plattformsoberoende design, vilket kan påverka flera operativsystem.
- Läckage av JavaScript utanför applikationen
Kort sagt så innebär användandet av Electron att många attacker som förut enbart vara relevanta för webbläsare och webbapplikationer nu är tillämpbara mot skrivbordsapplikationer. De resulterande konsekvenserna kan dessutom bli större till följd av Node.js:s djup integration mot det underliggande operativsystemet. Även om många av dessa funktioner kan stängas av vid uppbyggandet av Electron-applikationer så kan misstag innebära sårbarheter som ger fullständig kommandoexekveringsförmåga. Sårbarheter i Chromium skulle också potentiellt kunna utnyttjas för att utföra exempelvis spoofing attacker, omdirigera och imitera andra sidor inuti applikationen för att lura användaren och kapa information. Alla eventuella säkerhetsnackdelar som har att göra med JavaScript förs likaså vidare.
Flera av dessa farhågor går bortom enbart de konceptuella. Under det senaste året har ett flertal sårbarheter uppdagats som har påverkat Electron baserade applikationer. Somliga av dessa drabbade ramverket direkt vilket gjorde att alla applikationer var utsatta. Det värsta är att flera av dessa innebar fullständig fjärrkommandoexekveringsförmåga. Några exempel är (notera att detta inte är alla sårbarheter):
- Kommandoexekveringsförmåga till följd av sårbarhet i Chromiums sandbox funktion (CVE-2017-16151)t
- Kommandoexekveringsförmåga i Signals Electron-applikation till följd av HTML tag injektion (CVE-2018-1000136)
- Kommandoexekveringsförmåga i vissa Electron baserade applikationer på Windows till följd av skräddarsydda protokoll identifierare (CVE-2018-1000006)
Alla dessa sårbarheter bör kategoriseras som allvarliga. I samtliga fall löstes dessa genom uppdateringar, dock under förutsättningen att utgivarna för applikationerna i sin tur uppdaterade den använda Electron versionen.
Till sist är det viktigt att betrakta förekomsten av dessa sårbarheten i sammanhang. Electron är grunden i många applikationer som i sin tur användes flitigt inom många företag och verksamhet. Skype, Slack och Signal står för en stor del av all kommunikation. Om dessa är installerade på maskiner inom interna nätverk, och har sårbarheter som kan bli utnyttjade enbart genom att sända speciella meddelanden (ej filer) kan de utgöra en framträdande säkerhetsrisk för hela företaget.
Hur ska vi betrakta Electron baserade applikationer säkerhetsmässigt?
Trots de uppenbara utvecklarfördelarna med Electron så symboliserar dess ökade förekomst ett säkerhetsmässigt bekymmer. En för många oväntat attackvektor exponeras och interna nätverk kan sakna direkta skyddsåtgärder för sådana angrepp. Det är vanligt att Slack eller Skype är en central beståndsdel av kommunikation i ett företag, både internt och externt. Frågan är om användare är lika förbereda på phishing attacker i dessa meddelandetjänster som de är på sådana som sker via email. Electron-applikationer kan därför utgöra en säkerhetsrisk som först initieras via en teknisk sårbarhet och sedan förstärks på grund av vanligt användar beteende. Om användandet av Electron fortsätter att öka bör flera bli underrättande om de medföljande säkerhetsriskerna. Eventuellt borde dessutom enheter som kör Electron baserade applikationer segmenteras från känsliga nätverksresurser. Vi borde helt enkelt vara mer misstänksamma mot den ökande förekomsten av Electron, speciellt på våra interna nätverk.
Referenser:
http://redmonk.com/sogrady/2018/03/07/language-rankings-1-18/
https://nvd.nist.gov/vuln/detail/CVE-2017-16151