Krytyczna podatność w Citrix Virtual Apps and Desktops

Rozwiązania takie jak Citrix Virtual Apps and Desktops pozwalają zmienić paradygmat pracy, dzięki scentralizowanej platformie, która odpowiada za wirtualizację, pracownicy mogą kontynuować wykonywanie swoich zadań od miejsca, w którym je skończyli na zupełnie innym urządzeniu. Centralizacja pozwala na ułatwienie zarządzania czy monitorowania, co może mieć pozytywny wpływ na bezpieczeństwo. Przeniesienie kluczowych zadań, na główny serwer pozwala też zredukować zapotrzebowanie na wydajność sprzętu osobistego, ponieważ najcięższe operacje wykonywane są na dużych serwerach, nie opuszczających budynku firmy. Tyle teoria, niepoprawne zaimplementowanie takich rozwiązań, skutkować może miernym user experience oraz frustracjami.

TLDR:

• badacze z WatchTowr znaleźli łańcuch podatności pozwalający na nieuwierzytelnione zdalne wykonanie kodu w Citrix Virtual Apps and Desktops
• przez zbieg okoliczności, wykorzystanie luki możliwe jest zdalnie
• skutki eksploitacji są całkiem poważne, ponieważ atakujący może wykonać dowolny kod na hoście, który wystawia do sieci interfejs po HTTPS. Nie potrzebuje do tego uwierzytelnienia
• jak na razie nie ma łatki ani CVE

Co może pójść źle, gdy połączymy deserializację oraz protokół, który przez przypadek jest kompatybilny z HTTP? Zdalne RCE bez uwierzytelnienia! Jak? Pokazał to zespół WatchTowr.

Monitoring w aplikacjach VDI został wyniesiony na nowy poziom. Na potrzeby np. kontroli lub po prostu rozwiązywania problemów, na które natrafiają użytkownicy, wprowadzono mechanizmy pozwalające administratorom na uzyskanie strumienia obrazu (klient łączący się do pulpitu zdalnego, z grubsza otrzymuje streaming video) prosto z instancji użytkownika. Citrix, według tego co zauważają badacze, potrafi nawet wznowić nagrywanie w momencie wykrycia czynności takich jak przeszukiwanie wrażliwych danych czy innych podejrzanych aktywności (obrazek 1). Użytkownik sam może wyzwolić nagrywanie ekranu, gdy chce np. uzupełnić swoje zgłoszenie problemu, dokumentując problematyczne działania. 

Nagrania są następnie umieszczane w specjalnej przestrzeni – łącznie z metadanymi. Aby uzyskać dostęp do tych nagrań, użytkownik musi dysponować odpowiednimi uprawnieniami. 

Okazuje się, że za obsługę nagrań odpowiada komponent SsRecStorageManager.exe. Badacze odnaleźli ciekawe zapisy w dokumentacji tego komponentu.

Citrix Session Recording Storage Manager is a Windows service that manages the recorded session files received from each Session Recording-enabled computer running XenApp and XenDesktop. The Storage Manager receives the session recordings as message bytes via the Microsoft Message Queuing (MSMQ) service. To maintain the integrity of the recordings at all times, the Storage Manager should be able to manage the received messages as quickly as they are sent by the Session Recording agent.

Nagrania są przesyłane w postaci bajtów z wykorzystaniem usługi Microsoft Message Queuing.  Dalsza analiza wskazała, że fragment kodu odpowiedzialny za obsługę zdarzenia EventMetadataWithTime równierz korzysta z tej usługii a ponadto wykorzystuje deserializację… Każdy kto zetknął się z deserializacją w .NET (lub przeczytał rozdział o deserializacji w .NET w BAW) domyśla się, w którym kierunku zmierza śledztwo zespołu badaczy WatchTowr. 

Autorzy oprogramowania wykorzystali tam znaną badaczom bezpieczeństwa (polecamy tutaj szczególnie prace nad uniwersalnymi gadżetami do deserializacji Piotra Bazydło, Jamesa Forshawa i innych znanych badaczy, których wysiłki zostały wykorzystane między innymi we frameworku ysoserial.net) klasę BinaryFomatter, która w dokumentacji oznaczona jest jako niebezpieczna. 

Aplikacja Citrixa udostępnia gadżet, znaleziony przez Jamesa Foreshawa, który pozwala w pewnych warunkach na osiągnięcie zdalnego wykonania kodu. Jednak dotarcie do miejsca, w którym jest on możliwy do użycia, wymaga jeszcze jednego – kluczowego kroku. Citrix domyślnie, (i bardzo dobrze) nie wystawia portu sieciowego, do komunikacji przez MSMQ. A to znaczy, że spreparowana wiadomość nie będzie mogła dotrzeć do podatnego kodu… To znaczy nie mogłaby, gdyby nie pewien zabawny (z punktu widzenia atakującego) fakt. 

Otóż analiza kodu exploita innej podatności, wskazuje, że domyślnie możliwe jest “tunelowanie” wiadomości MSMQ z wykorzystaniem HTTP. 

Zespół Citrixa postanowił domyślnie włączyć tę funkcjonalność. Zgodnie z przedstawioną przez badaczy analizą, nie jest ona niezbędna do funkcjonowania produktu.. co łamie zasadę domyślnego uruchamiania tylko najbardziej potrzebnego kodu – w efekcie zwiększa to powierzchnię ataku, a w tym przypadku – robi to bardzo skutecznie, bo wprost umożliwia jego przeprowadzenie.

WatchTowr zaprezentował również filmik z PoCem (ciekawe czy nagrywany przez VDI?)

https://x.com/i/status/1856366380163183103

Co robić? Na ten moment nie ma jeszcze patchy, a ponieważ MSMQ jest kluczowym komponentem Citrixa, to trudno mówić o możliwości jego wyłączenia lub ograniczenia. Badacze podkreślają, że badali tylko wersję Citrix_Virtual_Apps_and_Desktops_7_2402_LTSR, która według nich, w domyślnej konfiguracji jest podatna na zdalne wykonanie kodu przez udostępniany po HTTP[S] panel zdalnego pulpitu. Więcej szczegółów dowiemy się pewnie, gdy producent odniesie się do sytuacji…

~fc