Simovits

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:

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

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

Figur 1 Genom att ändra proxy-inställningarna till “manual” och sedan peka på 127.0.0.1:8080 så dirigerar vi alla HTTP/S-förfrågningar till Burp

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

Figur 2 Lyssnare konfigureras under Options-fliken. Notera att du behöver sätta upp två lyssnare (en för port 443 och en för 80)

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.

Publicerat 2020-07-24 Skrivet av Peter Hildeblom