Electron-applikationer – Framtiden eller den perfekta attackvektorn?: Del 1 av #
Jag fick tidigare under sommaren möjligheten till att lära mig om en ny approach till säkerhetstester. Denna gång i form av attacker mot skrivbordsapplikationer, och huvudsakligen Electron-baserade applikationer. För er som inte är välbekanta med Electron-applikationer så kan de summeras som en kombination av skrivbordsapplikationer och webbapplikationer. Bland annat så renderas GUI med CSS och HTML och funktioner byggs i JavaScript. Vi kommer därmed kunna applicera många tekniker från webbapplikationstester mot Electron-applikationer.
Troligtvis har du som läser blogginlägget redan Electron-applikationer installerade på din dator. Microsoft Teams, Github, Slack, Skype och Discord tillhör bland de mest populära Electron-applikationerna och används dagligen av hundratusentals användare.
I den här bloggen tänkte jag presentera några lärdomar som jag har tagit med mig från den tid jag spenderat med att testa Electron-applikationer. Ambitionen är att framtida blogginlägg i den här serien ska vara mer fokuserade på Electron-specifika angrepp medan det här inlägget är en mer generell introduktion.
Angreppsmetodik
Som tidigare nämnt så finner vi många likheter mellan Electron-applikationer och webbapplikationer.
Vår angreppsmetodik kan därmed utgå från ramverk som riktar in sig mot webbapplikationer, så som:
OWASP API Security Top 10 – https://owasp.org/www-project-api-security/
OWASP Top 10 Web Application Security Risks – https://owasp.org/www-project-top-ten/
Vi behöver också sätta upp en testmiljö där vi kan installera applikationen i en ”ren” miljö som inte påverkas av andra applikationer som vi har installerade på vår dator. För detta funkar valfri Linux-OS (förutsatt att applikationen finns tillgänglig för *nix) alternativt ett modernt Windows-OS som vi sätter upp som en virtuell maskin. Vi kommer även behöva lite verktyg för att underlätta testerna. Listan nedan innehåller några verktyg som är till stor hjälp:
- Burp Suite – Tillåter oss att manipulera förfrågningar som skickas av applikationen. https://portswigger.net
- Frida – Låter oss att hooka in i en process/applikation och därifrån analysera funktioner, injicera egna Javascript-snuttar, etc. https://frida.re/docs/home/
- Asar & JSBeautify – Verktyg för att packa upp Electron-applikationer, respektive: snygga upp JavaScript-filer så att de blir mer lättlästa för en människa. https://github.com/electron/asar & https://github.com/beautify-web/js-beautify
- BEEMKA – Ett exploit kit som låter oss kompilera en befintlig Electron-applikation med en bakdörr eller annan skadlig kod. – https://github.com/ctxis/beemka
Sårbara konfigurationer
Electron-applikationer har utöver sina många likheter med webbapplikationer också en del säkerhet som förlitar sig på inställningarna. En bra början i varje Electron-test är att undersöka konfigurationerna. Efter att vi packat upp vårt program så kan vi inspektera huvudprojektfilen i valfri textläsare. Här har vi två parametrar som är speciellt av intresse
- ContextIsolation – Detta är en funktion som har i uppgift att se till att preload-skript och Electrons interna logik körs i separata kontext. Kort och gott hindrar funktionen preload-skript från att kalla på funktioner som applikationen annars inte har definierat. ContextIsolation är som standard satt till True.
- NodeIntegration – Funktionen tillåter skript åtkomst till Node.JS-resurser. Som standard är funktionen satt till False.
Medan funktionerna i sig själva ser oskyldiga ut, så kan de om de är felkonfigurerade leda till att vi har en applikation där vi kan eskalera en Cross-Site Scripting-sårbarhet till en Remote Code execution-sårbarhet. Kombinationen vi söker är ContextIsolation = False och NodeIntegration = True. Medan det låter som en helt osannolik kombination, speciellt då de både är konfigurerade med säkra True & False-värden som standard, så är det ändå en kombination som dyker upp med jämna mellanrum. En av de drivande anledningarna till att utvecklare konfigurerar sina applikationer med osäkra inställningar är att respektive funktion kan leda till kompabilitet/exekveringsproblem när de annars är “korrekt” konfigurerade.
Givetvis kan vi hitta mer brister i konfigurationen som inte är direkt relaterade till ContextIsolation eller NodeIntegration. Jag rekommenderar Luca Carettonis presentation – Preloading Insecurity In Your Electron från Black Hat Asia 2019[1] för en djupdykning i brister som vi hittar i Electron-konfigurationen.
[1] https://doyensec.com/resources/Asia-19-Carettoni-Preloading-Insecurity-In-Your-Electron.pdf
Man-In-The-Middle (MiTM)
Vi vill nu sätta upp vår proxy (jag använder Burp Suite) så att vi kan fånga förfrågningar som går från applikationen och manipulera dem innan de tas emot av servern. Detta låter oss delvis se på vad som händer under utan på detaljnivå och även identifiera dolda parametrar och funktioner som kan visa sig innehålla sårbarheter. För enkelhetens skull så använder vi i guiden Ubuntu 16.04 och Burp Suite Community edition. Samma metod kan användas i Windows eller andra operativsystem samt med en annan proxy som har stöd för att sätta upp flera lyssnare. Detta kan dock kräva lite fler steg än vad som listas nedan.
Steg 1. Installation och export av certifikat
Burp Suite installeras genom java-klienten som finns att ladda ner på den officiella hemsidan[1]
Portswigger tillhandahåller också detaljerade instruktioner för felsökning och andra problem som kan uppstå vid installationssteget.
När vi väl har installerat Burp så vill vi först skapa ett temporärt projekt som vi kommer använda för att exportera SSL-certifikatet. Efter att ha startat igång vårat projekt så navigerar vi till fliken Proxy > Options > Import/Export CA Certificates
Vi vill nu konvertera vårat certifikat från .der till .crt-format. Detta gör vi med kommandot
openssl x509 -in burp.der -inform DER -out burp.crt -outform PEM
Därefter behöver vi importera certifikatet i nssdb-databasen då det är där Electron-applikationer letar efter giltiga certifikat (på *nix)
Vi använder vårt tidigare konverterade burp-certifikat och importerar det via följande kommando
certutil -A -d sql:$home/.pki/nssdb -n burp -i /usr/local/share/ca-certificates/burp.crt -t “CT,C,C”
Notera att sökvägen behöver justeras för att peka på platsen där du exporterat ditt certifikat.
Steg 2. Ändring av proxykonfiguration
Med Ubuntu kan vi lätt ändra proxy:n för operativsystemet via GUI:t i fliken ”Settings
Alternativt kan vi köra följande kommandon i terminalen
export http_proxy=’http://127.0.0.1:8080’
export https_proxy=’http://127.0.0.1:8080’
Steg 3. Starta igång din applikation och verifiera att allt fungerar
Om allting fungerar som det ska så ska Burp nu fånga upp förfrågningar som skickas från applikationen. Verifiera att allting fungerar genom att starta igång applikationen du ska testa samtidigt som Burp är igång och kontrollera att förfrågningar går genom Burp.
[2] https://portswigger.net
Steg 3. Starta igång din applikation och verifiera att allt fungerar
Om allting fungerar som det ska så ska Burp nu fånga upp förfrågningar som skickas från applikationen. Verifiera att allting fungerar genom att starta igång applikationen du ska testa samtidigt som Burp är igång och verifiera att förfrågningar går genom Burp.
MiTM via DNS-spoofing
Om inte det första alternativet av MiTM skulle vara applicerbart kan vi istället utföra MiTM med hjälp av DNS-spoofing.
För denna metod behöver vi inventera vilka servrar vår applikation pratar med.
I detta exempel använder vi programvaran Skype som talar med många servrar. Bland annat
browser.pipe.aria.microsoft.com
config.edge.skype.com
login.live.com
…
…
Vi vill nu ändra /etc/hosts sådant att den dirigerar förfrågningar mot dessa servrar via localhost
Din /etc/hosts fil bör se ut på följande sätt
127.0.0.1 browser.pipe.aria.microsoft.com
127.0.0.1 config.edge.skype.com
127.0.0.1 login.live.com
Därefter behöver vi konfigurera Burp till att lyssna på port 80 och 443 med två separata lyssnare
Alla förfrågningar vi skickar mot dessa servrar går nu via vår lokala proxy. Smidigt om det inte skulle fungera med våra operativsystemsinställningar för proxy!
Jakten på sårbarheter
Vi har nu satt upp vår miljö och proxy och är nu redo att testa applikationen. Som tidigare nämnt delar Electron-applikationer mycket likheter med webbapplikationer och vi vill därför testa fält och funktioner för sårbarheter som XSS, SQL-injektioner, med mera. Electron-applikationer kan även dra nytta av API:n, så även OWASP Top 10 API kan vara till stor nytta. Under testerna behöver vi även dra nytta av det vi lärde oss i tidigare steg. Om vi exempelvis identifierar en XSS-sårbarhet i ett fält och sedan tidigare vet att applikationen är dåligt konfigurerad så kan vi en simpel injektion utföra en RCE-attack. Möjligheten till att identifiera sårbarheter slutar inte vid webb och API-sårbarheter. Electron själv har haft ett flertal sårbarheter som identifierats under årens lopp och senast 7:e juli 2020 publicerades fyra nya sårbarheter för Electron av version 8.2.3 eller tidigare. Vi bör därmed vara uppmärksamma på vilken version av Electron applikationen är skriven i.
Ett paket kommer lastat
Vi kan uppnå olika resultat med Electron-applikationer beroende på vad målet med våra tester är. Om målet ligger i att infiltrera en organisation så kan vi utnyttja Electrons metodik för att lätt packa upp och paketera program. Vi drar här nytta av ramverket BEEMKA som hjälper oss paketera om Electron-applikationer med skadlig kod, så som bakdörrar eller spionprogram.
Verktyget kräver minimal insats och vi kan via ett kommando kompilera om en programvara till att innehålla en bakdörr. Exempelvis:
Python3 beemka.py -i -f /usr/share/teams/resources/electron.asar -p /tmp/beemka -o output.asar -m keylogger
Ovanstående kommando resulterar i en version av Microsoft Teams med en keylogger. Beemka startar automatiskt upp en avlyssnare som tar emot knapptryckningar från varje användare som laddar ner vår modifierade version av Teams och exekverar programvaran.
Slutord
Att testa Electron-applikationer har inte sett samma ökning i popularitet likt webbapplikationer. Trots det så delar både typerna av applikationer mycket likheter och argumentet kan också föras att Electron-applikationer är lättare att granska då vi har tillgång till mycket av källkoden genom att packa upp programvaran, samt har en större attackvektor. Beroende på hur framtiden ser ut så kan vi komma se fler Electron-applikationer på marknaden och ett större intresse för denna typ av säkerhetstester.
Jag vill passa på att tacka för Abraham Aranguren och 7ASecurity för kursen ”Hacking Modern Desktop apps” som väckte mitt intresse för Electron-applikationer.