Bug hunter, zgodnie z opisem na swoim blogu – 19-latek z Brazylii, odkrył możliwość przenikania do prywatnych profili firm w portalu Workplace by Facebook, za co został nagrodzony kwotą 27,5tys. dolarów w programie Bug Bounty. Na czym polegała podatność?
Workplace by Facebook – co to?
Facebook poza główną częścią sieci społecznościowej, którą dobrze znamy (ponoć w Polsce jest ponad 23 miliony użytkowników Facebooka), posiada także mniejsze sieci i funkcjonalności powiązane ze sobą.
Jedną z inicjatyw Facebooka jest Workplace by Facebook (https://www.workplace.com/). Jest to sieć społecznościowa przeznaczona dla firm – na ich wewnętrzny użytek. Aby z niej skorzystać, konkretna firma wykupuje w niej „abonament”, a następnie może oferować swoim pracownikom i kontrahentom możliwości swego rodzaju „prywatnej” sieci społecznościowej podobnej do Facebooka.
Podatna funkcjonalność
Problemem okazała się funkcjonalność „self-invite”. Zarządzając panelem swojej organizacji, administrator może włączyć opcję „self-invite”. Kiedy jest ona włączona, osoby rejestrujące się za pomocą e-maila pochodzącego z domeny „zaufanej” nie podlegają weryfikacji przez administratora, czyli w skrócie – zakładamy, że każdy, kto ma maila w domenie mojafirmowadomena.com jest na sto procent osobą zaufaną, i jeżeli będzie chciał się zarejestrować do naszego firmowego „workplace”, to może zrobić to bez kontroli administratora. No dobrze, ale gdzie tu problem? W końcu firmowe e-maile zazwyczaj nie są rozdawane byle komu?
Co z tą weryfikacją
Zgodnie z powyższym, posiadania maila w domenie firmowej powinno być warunkiem rejestracji do organizacji bez kontroli administratora. Problem polegał na tym, że domena adresu e-mail nie była w ogóle weryfikowana! Odkrywca podatności po prostu zarejestrował się z pomocą prywatnego adresu ze skrzynki na gmail.com. Po „dodaniu się” do sieci firmowej miał dostęp do różnego rodzaju materiałów, które zazwyczaj znajdują się w korporacyjnym intranecie – prywatnych danych firmowych, planów strategii, wieści z życia firmy, zdjęć i danych pracowników.
Podatność okazała się być klasycznym problemem typu IDOR (Insecure Direct Object Reference).
Jak przebiegał atak
Znalezienie podatności rozpoczęto od inspekcji ruchu aplikacji mobilnej na Androida – badacz nie zdradza, czy różnił się od jakoś od wersji webowej, nie mniej jednak był to jego punkt wejścia.
Koniecznym warunkiem było także poznanie „community_id” określonej organizacji – czyli identyfikatora numerycznego, unikalnego dla każdej firmy mającej swoją sieć w workplace – jednak w późniejszym okresie (już po zgłoszeniu bug’a) okazało się, że istnieje w aplikacji endpoint, który pozwala na enumerację identyfikatorów poszczególnych organizacji.
Badacz przeanalizował żądanie rejestracji nowego użytkownika i doszedł do wniosku, że jeśli zmanipuluje parametr „community_id”, to konto zostanie utworzone nie w zarządzanej przez niego organizacji, ale w jakiejś innej – tej, której community_id podamy w parametrze (oczywiście jeżeli ona również ma włączoną opcję „self registration”).
Znając community_id, wykorzystanie podatności ograniczało się do dwóch żądań HTTP:
1. Atakujący korzystając z swojego aktualnego „access tokenu” (swojego identyfikatora sesji) uzyskuje „activation code” – jest to standardowy flow aplikacji:
POST /at_work/accounts_send_notification HTTP/1.1
Host: graph.workplace.comidentifier=test@gmail.com
pre_login_flow_type=SIGNUP
access_token=*****
2. Następnie korzystając z otrzymanego w odpowiedzi na poprzednie żądanie „activation code”, umieszcza go w parametrze „nonce”. Dodaje także dane rejestracji nowego użytkownika (login i hasło) oraz commnity_id innej firmy.
POST /at_work/accounts_self_invite HTTP/1.1
Host: graph.workplace.com
identifier=email-atakującego@gmail.com
nonce=998236
community_id=[ID Organizacji, do której się przyłączamy]
form_data={"name":"Test","password":"Test1234@"}
access_token=*****
To wszystko. Od teraz atakujący ma dostęp do wewnętrznej „społeczności” zaatakowanej firmy.
Jak widać, podatności typu IDOR mogą prowadzić do niezwykle poważnych konsekwencji, a ich wykorzystanie nie jest specjalnie trudne – choć w tym przypadku konieczne było znalezienie punktu wejścia, który był nietypowy i zależał od niestandardowej opcji „self-invite”.
Źródło:
https://mvinni.medium.com/workplace-by-facebook-unauthorized-access-to-companies-environment-27-5k-a593a57092f1
