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 „prywatnejsieci 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 domenyzaufanej” 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ętrznejspoł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

0 CommentsZamknij komentarze

Skomentuj