Zoom dla Maca łata podstępny błąd „szpieg na mnie” – zaktualizuj teraz!

Popularna i wszechobecna (oprogramowanie nie zawsze jest obiema tymi rzeczami!) Firma Zoom, zajmująca się spotkaniami w chmurze, niedawno ogłosiła błąd, który nie powinien się wydarzyć w wersji swojego oprogramowania na komputery Mac.

Biuletyn bezpieczeństwa jest, co można wybaczyć, napisany w typowym staccato i przesiąkniętym żargonem stylu łowców błędów, ale znaczenie jest dość jasne.

Błąd jest oznaczony CVE-2022-28762, i jest szczegółowo opisany w Biuletyn Zoom ZB-22023:

Gdy kontekst renderowania w trybie aparatu jest włączony w ramach interfejsu Zoom App Layers API przez uruchomienie niektórych aplikacji Zoom, lokalny port debugowania jest otwierany przez klienta Zoom.

Gdzie chciałbyś dzisiaj pojechać?

„Port debugowania” zwykle odnosi się do nasłuchującego połączenia sieciowego, zwykle gniazda TCP, które obsługuje żądania debugowania.

W ten sam sposób, w jaki serwer pocztowy zwykle nasłuchuje na porcie TCP 25, czekając, aż zdalni klienci poczty e-mail „zadzwonią” przez sieć i zażądają pozwolenia na dostarczanie wiadomości przychodzących, porty debugujące nasłuchują na wybranym przez siebie porcie (często konfigurowalnym, choć czasami tylko w nieudokumentowany sposób) dla połączeń przychodzących, które chcą wydawać polecenia debugowania.

Jednak w przeciwieństwie do serwera poczty e-mail, który akceptuje żądania związane z dostarczaniem wiadomości (np MAIL FROM i RCPT TO), debugowanie połączeń zwykle zapewnia znacznie bardziej intymną interakcję z aplikacją, z którą się łączysz.

Rzeczywiście, porty debugowania generalnie pozwalają nie tylko dowiedzieć się o konfiguracji i wewnętrznym stanie samej aplikacji, ale także wydawać polecenia bezpośrednio do aplikacji, w tym polecenia osłabiające bezpieczeństwo, które nie są dostępne dla zwykłych użytkowników za pośrednictwem zwykłego interfejsu użytkownika.

Na przykład serwer poczty e-mail zazwyczaj pozwala na wysłanie wiadomości na swój port TCP dla wybranej nazwy użytkownika, ale nie pozwala na wysyłanie poleceń zmieniających konfigurację samego serwera i nie pozwala na wyodrębnienie tajnych informacji takie jak statystyki serwera lub wiadomości innych osób.

W przeciwieństwie do tego, są to dokładnie te „funkcje”, na które zwykle zezwalają porty debugowania, dzięki czemu programiści mogą dostosowywać i monitorować zachowanie swojej aplikacji podczas rozwiązywania problemów, bez konieczności przechodzenia przez zwykły interfejs użytkownika.

(Możesz zobaczyć, jak ten rodzaj „kanału bocznego” do wnętrzności aplikacji byłby szczególnie przydatny, gdy próbujesz debugować sam interfejs użytkownika, biorąc pod uwagę, że użycie interfejsu użytkownika do debugowania interfejsu użytkownika prawie na pewno przeszkadzałoby z tymi samymi pomiarami, które próbowałeś wykonać.)

Warto zauważyć, że porty debugowania zazwyczaj pozwalają uzyskać rodzaj „wewnętrznego widoku” samej aplikacji, na przykład: zaglądanie do obszarów pamięci, które zwykle nigdy nie byłyby widoczne dla użytkowników aplikacji; przechwytywanie migawek danych, które mogą zawierać poufne dane, takie jak hasła i tokeny dostępu; i wyzwalanie przechwytywania audio lub wideo bez powiadamiania użytkownika…

…wszystko to w pierwszej kolejności bez logowania do aplikacji lub usługi.

Innymi słowy, debugowanie portów jest złem koniecznym do wykorzystania podczas tworzenia i testowania, ale nie powinno się ich aktywować, a najlepiej nawet, aby być aktywowane podczas regularnego korzystania z aplikacji, ze względu na oczywiste luki w zabezpieczeniach, które wprowadzają.

Hasło nie jest potrzebne

Mówiąc ogólnie, jeśli masz dostęp do portu TCP, na którym nasłuchuje debuger, i możesz utworzyć z nim połączenie TCP, to jest całe uwierzytelnianie, którego potrzebujesz, aby przejąć aplikację.

I właśnie dlatego porty debugowania są zazwyczaj włączane tylko w ściśle kontrolowanych okolicznościach, kiedy wiesz, że rzeczywiście chcesz umożliwić programiście wędrowanie po aplikacji, ciesząc się tym, co jest skutecznie nieuregulowanym i potencjalnie niebezpiecznym dostępem do supermocy .

Rzeczywiście, wiele produktów oprogramowania jest celowo zbudowanych w dwóch różnych wersjach: kompilacja debugowania, w której debugowanie można włączyć w razie potrzeby, oraz kompilacja wydania, w której funkcje debugowania są całkowicie pominięte, więc nie można ich w ogóle aktywować, czy to przez wypadek lub projekt.

Telefony z systemem Android firmy Google zawierają tryb debugowania, w którym można podłączyć kabel USB i wkopać się do telefonu (choć nie z pełnymi uprawnieniami roota) z laptopa za pomocą tego, co jest znane jako ADB, skrót od Most debugowania Androida. Aby w ogóle włączyć debugowanie, musisz najpierw kliknąć Ustawienia > O telefonie > Numer kompilacji siedem razy (naprawdę!) z rzędu. Dopiero wtedy opcja włączenia debugowania pojawia się nawet w menu, gdzie można ją aktywować w Ustawienia > Konfiguracja > Zaawansowane > Opcje dla programistów > debugowanie USB. Następnie, po podłączeniu i próbie połączenia z laptopa, musisz autoryzować połączenie za pomocą wyskakującego ostrzeżenia w samym telefonie. Z pewnością możesz to zrobić celowo, jeśli masz fizyczny dostęp do odblokowanego telefonu, ale jest to mało prawdopodobne, aby stało się to przez pomyłkę.

Dla dodatkowego bezpieczeństwa porty debugowania są często konfigurowane tak, aby nie akceptowały połączeń przychodzących z innych komputerów (w kategoriach technicznych nasłuchują tylko na interfejsie „localhost”).

Oznacza to, że atakujący, który chce nadużyć niewłaściwie włączonego interfejsu debugowania, najpierw potrzebowałby przyczółka na twoim komputerze, na przykład jakiegoś złośliwego oprogramowania proxy, które samo akceptuje połączenia przez Internet, a następnie przekazuje swoje pakiety sieciowe do interfejsu sieciowego „localhost”.

Pomimo potrzeby pewnego rodzaju lokalnego dostępu w przypadku CVE-2022-28762, Zoom przyznał temu błędowi „wynik ważności” CVSS wynoszący 7.3/10 (73%) i ocenę pilności Wysoki.

Lokalne połączenia sieciowe TCP są zazwyczaj zaprojektowane do pracy ponad granicami użytkowników i procesów, więc atakujący nie musiałby być zalogowany jako Ty (lub jako administrator), aby nadużyć tego błędu – każdy proces, nawet program działający w bardzo ograniczonym konto gościa, może być w stanie cię szpiegować do woli.

Co więcej, ponieważ polecenia oprogramowania wydawane przez port debugowania zwykle działają niezależnie od zwykłego interfejsu użytkownika aplikacji, prawdopodobnie nie zobaczysz żadnych oznak, że Twoja sesja Zoom została przejęta w ten sposób.

Gdyby atakujący aktywował aplikację za pomocą bardziej konwencjonalnych kanałów zdalnego sterowania Mac, takich jak udostępnianie ekranu (VNC), miałbyś przynajmniej szansę zauważyć, że atakujący porusza wskaźnikiem myszy, klika przyciski menu lub wpisuje tekst…

…ale poprzez interfejs debugowania, który jest zasadniczo celowym tylnym wejściem, możesz być w błogiej nieświadomości (a być może nawet nie być w stanie wykryć), że osoba atakująca szpieguje Cię bardzo osobiście, używając kamery internetowej i mikrofonu.

Co robić?

Na szczęście własny zespół ds. bezpieczeństwa Zoom zauważył, co, jak zakładamy, było błędem w czasie kompilacji (funkcja, która pozostała włączona, która powinna zostać pominięta) i niezwłocznie zaktualizował wadliwe oprogramowanie Mac.

Zaktualizuj klienta macOS Zoom do wersja 5.12.0 lub nowsza a port debugowania pozostanie zamknięty, gdy użyjesz Zoom.

Na komputerze Mac przejdź do głównego zoom.us menu i wybierz Check for Updates... aby sprawdzić, czy masz najnowszą wersję.

---