macOS Electron Applications Injection
Last updated
Last updated
Dowiedz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Dowiedz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Jeśli nie wiesz, czym jest Electron, możesz znaleźć wiele informacji tutaj. Ale na razie wiedz, że Electron uruchamia node. A node ma pewne parametry i zmienne środowiskowe, które można wykorzystać do wykonania innego kodu oprócz wskazanego pliku.
Poniższe techniki zostaną omówione później, ale w ostatnim czasie Electron dodał kilka flag bezpieczeństwa, aby im zapobiec. Są to Bezpieczniki Electrona, a te są używane do zapobiegania aplikacjom Electrona w macOS przed ładowaniem dowolnego kodu:
RunAsNode: Jeśli jest wyłączony, zapobiega użyciu zmiennej środowiskowej ELECTRON_RUN_AS_NODE do wstrzykiwania kodu.
EnableNodeCliInspectArguments: Jeśli jest wyłączony, parametry takie jak --inspect, --inspect-brk nie będą respektowane. Unikając w ten sposób wstrzykiwania kodu.
EnableEmbeddedAsarIntegrityValidation: Jeśli jest włączony, załadowany plik asar będzie zweryfikowany przez macOS. Zapobiegając w ten sposób wstrzykiwaniu kodu poprzez modyfikację zawartości tego pliku.
OnlyLoadAppFromAsar: Jeśli jest to włączone, zamiast szukać do załadowania w następującej kolejności: app.asar, app i w końcu default_app.asar. Będzie sprawdzał i używał tylko app.asar, co zapewnia, że gdy jest połączony z bezpiecznikiem embeddedAsarIntegrityValidation, jest niemożliwe do załadowania niezweryfikowanego kodu.
LoadBrowserProcessSpecificV8Snapshot: Jeśli jest włączony, proces przeglądarki używa pliku o nazwie browser_v8_context_snapshot.bin dla swojego migawkowego V8.
Innym interesującym bezpiecznikiem, który nie będzie zapobiegał wstrzykiwaniu kodu, jest:
EnableCookieEncryption: Jeśli jest włączony, przechowywane na dysku ciasteczka są szyfrowane za pomocą kluczy kryptograficznych na poziomie systemu operacyjnego.
Możesz sprawdzić te flagi z aplikacji za pomocą:
Jak wspominają dokumenty, konfiguracja bezpieczników Electron jest skonfigurowana wewnątrz binariów Electron, które zawierają gdzieś ciąg znaków dL7pKGdnNz796PbbjQWNKmHXBZaB9tsX.
W aplikacjach macOS znajduje się to zazwyczaj w application.app/Contents/Frameworks/Electron Framework.framework/Electron Framework
Możesz załadować ten plik w https://hexed.it/ i wyszukać poprzedni ciąg znaków. Po tym ciągu znaków w kodzie ASCII zobaczysz liczbę "0" lub "1", wskazującą, czy każdy bezpiecznik jest wyłączony czy włączony. Po prostu zmodyfikuj kod szesnastkowy (0x30 to 0, a 0x31 to 1) aby zmienić wartości bezpieczników.
Należy zauważyć, że jeśli spróbujesz nadpisać binarny plik Electron Framework wewnątrz aplikacji z tymi zmienionymi bajtami, aplikacja nie będzie działać.
Może istnieć zewnętrzne pliki JS/HTML, które wykorzystuje Aplikacja Electron, więc atakujący może wstrzyknąć kod w te pliki, których sygnatura nie będzie sprawdzana i wykonać dowolny kod w kontekście aplikacji.
Jednakże, w chwili obecnej istnieją 2 ograniczenia:
Wymagane jest uprawnienie kTCCServiceSystemPolicyAppBundles do modyfikacji Aplikacji, więc domyślnie to nie jest już możliwe.
Skompilowany plik asap zazwyczaj ma bezpieczniki embeddedAsarIntegrityValidation i onlyLoadAppFromAsar włączone
Co sprawia, że ścieżka ataku jest bardziej skomplikowana (lub niemożliwa).
Należy zauważyć, że możliwe jest obejście wymagania kTCCServiceSystemPolicyAppBundles poprzez skopiowanie aplikacji do innego katalogu (np. /tmp), zmianę nazwy folderu app.app/Contents na app.app/NotCon, modyfikację pliku asar swoim złośliwym kodem, zmianę nazwy z powrotem na app.app/Contents i uruchomienie go.
Możesz rozpakować kod z pliku asar za pomocą:
I spakuj to z powrotem po dokonaniu modyfikacji za pomocą:
ELECTRON_RUN_AS_NODEZgodnie z dokumentacją, jeśli ta zmienna środowiskowa jest ustawiona, proces zostanie uruchomiony jako zwykły proces Node.js.
Jeśli flaga RunAsNode jest wyłączona, zmienna środowiskowa ELECTRON_RUN_AS_NODE zostanie zignorowana, i to nie zadziała.
Jak zaproponowano tutaj, można nadużyć tej zmiennej środowiskowej w pliku plist, aby utrzymać trwałość:
NODE_OPTIONSMożesz przechowywać ładunek w innym pliku i go wykonać:
Jeśli bezpiecznik EnableNodeOptionsEnvironmentVariable jest wyłączony, aplikacja zignoruje zmienną środowiskową NODE_OPTIONS podczas uruchamiania, chyba że zmienna środowiskowa ELECTRON_RUN_AS_NODE jest ustawiona, co również będzie ignorowane, jeśli bezpiecznik RunAsNode jest wyłączony.
Jeśli nie ustawisz ELECTRON_RUN_AS_NODE, otrzymasz błąd: Most NODE_OPTIONs are not supported in packaged apps. See documentation for more details.
Możesz nadużyć tej zmiennej środowiskowej w pliku plist, aby utrzymać trwałość, dodając te klucze:
Zgodnie z tym, jeśli uruchomisz aplikację Electron z flagami takimi jak --inspect, --inspect-brk i --remote-debugging-port, port debugowania będzie otwarty, dzięki czemu będziesz mógł się do niego podłączyć (na przykład z Chrome w chrome://inspect) i będziesz mógł wstrzykiwać w niego kod lub nawet uruchamiać nowe procesy.
Na przykład:
Jeśli bezpiecznik EnableNodeCliInspectArguments jest wyłączony, aplikacja zignoruje parametry node (takie jak --inspect) podczas uruchamiania, chyba że zmienna środowiskowa ELECTRON_RUN_AS_NODE jest ustawiona, co również zostanie zignorowane, jeśli bezpiecznik RunAsNode jest wyłączony.
Jednakże nadal można użyć parametru electron --remote-debugging-port=9229, ale poprzedni ładunek nie zadziała do uruchomienia innych procesów.
Korzystając z parametru --remote-debugging-port=9222 można ukraść pewne informacje z aplikacji Electron, takie jak historia (z poleceniami GET) lub ciasteczka przeglądarki (ponieważ są odszyfrowane wewnątrz przeglądarki i istnieje punkt końcowy json, który je udostępni).
Możesz dowiedzieć się jak to zrobić tutaj i tutaj oraz użyć automatycznego narzędzia WhiteChocolateMacademiaNut lub prostego skryptu jak:
W tym wpisie na blogu, to debugowanie jest wykorzystywane do spowodowania, że headless chrome pobiera dowolne pliki w dowolne lokalizacje.
Możesz wykorzystać tę zmienną środowiskową w pliku plist, aby zachować trwałość, dodając te klucze:
Demon TCC z macOS nie sprawdza wykonanej wersji aplikacji. Jeśli więc nie możesz wstrzyknąć kodu do aplikacji Electron żadną z poprzednich technik, możesz pobrać poprzednią wersję aplikacji i wstrzyknąć w nią kod, ponieważ nadal uzyska uprawnienia TCC (chyba że pamięć podręczna zaufania temu zapobiegnie).
Poprzednie techniki pozwolą ci uruchomić kod JS w procesie aplikacji elektronowej. Jednak pamiętaj, że procesy potomne działają w ramach tego samego profilu piaskownicy co aplikacja nadrzędna i dziedziczą swoje uprawnienia TCC. Dlatego jeśli chcesz nadużyć uprawnień, aby na przykład uzyskać dostęp do kamery lub mikrofonu, po prostu uruchom inny plik binarny z procesu.
Narzędzie electroniz3r można łatwo użyć do znalezienia podatnych aplikacji elektronowych zainstalowanych i wstrzyknięcia w nich kodu. To narzędzie spróbuje użyć techniki --inspect:
Musisz go skompilować samodzielnie i możesz go użyć w ten sposób:
Ucz się i praktykuj Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i praktykuj Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
