Gdzie leży granica bug bounty czyli ciekawy przypadek kluczy AWS Instagrama

Zdobycie pełnego dostępu do infrastruktury jednego z największych serwisów internetowych jakim jest Instagram wydaje się być całkiem niezłym osiągnięciem dla nieznanego szerzej hakera. Dlaczego Facebook nie wypłacił sowitej nagrody i czy miał rację?

W tej historii nie brakuje kontrowersji. Czy włamywacz po uzyskaniu dostępu do serwera i zgłoszeniu sukcesu w ramach programu bug bounty powinien pobierać jego konfigurację i szukać kolejnych danych umożliwiających kontynuację penetracji? Z drugiej strony czy Facebook powinien dzwonić do firmy zatrudniającej włamywacza i wspominać o armii prawników?

Zapomniany serwer z zapomnianą aplikacją

Historia zaczyna się na kanale IRC, na którym Wes Wineberg dowiedział się, że pod adresem https://sensu.instagram.com stoi serwer z panelem administracyjnym oraz potencjalnie podatną wersją Ruby / Rails. Wes od lat zajmuje się zawodowo i hobbystycznie testami penetracyjnymi i wiele razy brał udział w programach bug bounty, zatem postanowił spróbować swojego szczęścia. Testy przeprowadzał prywatnie, w wolnym czasie, chociaż firma dla której pracuje również zajmuje się takimi zleceniami.

Początkowo próbował wykorzystać błąd CVE-2013-3221 do resetu hasła, ale bez powodzenia. Potrzebował informacji o procesie resetowania hasła w tej konkretnej aplikacji. Na GitHubie znalazł repozytorium Sensu Admin a w nim, w pliku secret_token.rb, tajny token Railsów. Co prawda założenie że administratorzy Instagrama nie zmienili tej domyślnej wartości wydawało się trochę naciągane, ale Wes postanowił spróbować i wykorzystać token do podpisania ciasteczka wykorzystującego błąd deserializacji danych. Ku jego zaskoczeniu serwer Instagrama wykonał przekazane w ciasteczku polecenie i połączył się z jego serwerem. Kiedy uzyskał już zdalny dostęp do powłoki na serwerze swoje odkrycia (domyślny token oraz stara wersja Rails podatna na błąd deserializacji) zgłosił w raporcie programu bug bounty.

Musimy zejść głębiej

Mimo zgłoszenia nikt nie wyłączył serwera, zatem Wes postanowił grzebać dalej. Przestudiował reguły programu bug bounty i wyczytał, ze powinien unikać naruszania prywatności użytkowników oraz wyłączania serwerów, natomiast program zachęcał do prób uzyskania dostępów do systemów znajdujących się w infrastrukturze firmy. Wes odczytał to jako zaproszenie do dalszej penetracji. Zaczął od 60 kont administracyjnych do panelu Sensu. Co prawda hasze haseł były zapisane za pomocą wymagającej obliczeniowo funkcji bcrypt, ale okazało się, że sporo haseł było dość trywialnych. Sześć brzmiało changeme (zmień mnie), trzy były identyczne z nazwą użytkownika, dwa brzmiały password a jedno instagram. Po potwierdzeniu że hasła działają Wes stworzył kolejny raport do programu bug bounty (słabe hasła).

Interfejs Sensu

Wesowi ciągle było mało, zatem szukał dalej. Trafił na plik /etc/sensu/config.json, w którym znalazł między innymi klucze AWS. Po ich zaimportowaniu zobaczył 82 koszyki (buckets), lecz dostęp miał tylko do jednego. W nim z kolei znalazł pliki z archiwum skryptów zarządzających infrastrukturą Instagrama, a w nich kolejną parę kluczy, dających tym razem pełen dostęp do wszystkich koszyków. W nich znalazł niezłą kolekcję skarbów:

• statyczną wersję WWW Instagram.com,
• kod źródłowy mechanizmów Instagrama,
• certyfikaty SSL i klucze prywatne, włącznie z instagram.com,
• klucze OAuth oraz APi Instagrama,
• klucze do podpisywania aplikacji na iOS i Androida,
• klucze API Twittera, Facebooka, Flickra, Tumblra, Foursquare i Recaptcha.

Wes swoje znaleziska opisał w kolejnym raporcie, wskazując, jakie błędy m. in. rozdziału dostępu do zasobów spowodowały, że uzyskał dostęp do sporej ilości informacji. Po kilku dniach od pierwszego zgłoszenia Facebook zablokował dostęp do serwera.

Kontrowersje

Pierwsze odpowiedzi Facebooka nieco zdziwiły Wesa. Usłyszał, że po uzyskaniu dostępu do serwera nie powinien dalej grzebać, tylko czekać na reakcję Facebooka. Choć wydaje się to standardem przyzwoitości badacza, to Wes nie znalazł takich zapisów w regułach programu bug bounty. Wkrótce jego zgłoszenie zostało zamknięte a Wes został poinformowany, że sposób wykorzystanie błędu był w sprzeczności z zasadami programu i nie zostanie mu wypłacona nagroda. Sam badacz poinformował Facebooka, że zamierza opublikować szczegółowe informacje dotyczące swoich odkryć.

Wieczorem tego samego dnia którego Wes zgłosił ostatnie błędy Facebookowi zadzwonił do niego jego przełożony.  Oznajmił, że jest w pokoju z dyrektorem IT firmy, w której pracuje Wes i są po rozmowie z Aleksem Stamosem, szefem bezpieczeństwa Facebooka. Według relacji Wesa Stamos miał poinformować jego szefów, że Wes znalazł mało istotny błąd na serwerach Instagrama i uzyskał dostęp do poufnych danych. Facebook oczekiwał, ze Wes skasuje pobrane dane i zaniecha publikacji na temat swoich odkryć a interwencja prawników ani organów ścigania nie będzie konieczna…

Facebook przyjął zgłoszenie zdalnego wykonania kodu (pierwsze z przesłanych przez Wesa) i zgodził się wypłacić za nie 2500 dolarów. Pozostałe zgłoszenia zostały odrzucone ze względu na naruszenie reguł programu.

Po tym jak Wes opublikował historię całego konfliktu, głos zabrał także Alex Stamos. Alex podkreślił, że zawsze stał po stronie badaczy w walce z korporacjami. Poinformował, że znalezienie kluczy AWS na serwerze trudno potraktować jako naruszenie bezpieczeństwa, ponieważ tam własnie powinny się znajdować i to ich wykradzenie stanowiło naruszenie reguł programu bug bounty. Podobno Facebook został zaskoczony przez Wesa informacją o zakresie jego odkryć po tym, jak Wes wyraził zdziwienie niską kwotą nagrody (miał otrzymać jedynie 2500 dolarów ponieważ nie był jedynym zgłaszającym dostępność panelu Sensu). Alex także dość mętnie tłumaczy, dlaczego odezwał się bezpośrednio do pracodawcy Wesa (powołuje się na mocno naciągane informacje jak np. informacja na profilu Wesa o jego miejscu pracy).

Nasza opinia

W naszej ocenie obie strony popełniły swoje błędy. Choć penetrowanie zasobów Instagrama musiało być ciekawym doświadczeniem, to jednak intuicja i zdrowy rozsądek podpowiadają nam, że żadna firma organizująca bug bounty i nie zachęcająca wprost do kontynuowania penetracji sieci i serwerów nie powinna być zadowolona z takiego rozwoju wydarzeń. Również rozmowy ze znajomymi pentesterami potwierdzają, że to, co zrobił Wes, znacznie wykracza poza zwyczajowy zakres testów w programie bug bounty, które z reguły po uzyskaniu możliwości wykonania dowolnego kodu kończą się krótkim potwierdzeniem znaleziska. Oczywiście inaczej sprawa wygląda w zleceniu typu „wszystkie chwyty dozwolone”, gdzie kończy się przejęciem kontrolera domeny lub analogicznej maszyny, jednak to nie o taki przypadek tutaj chodziło. Co prawda Wes podkreśla, że reguły programu bug bounty nie zakazywały tego, co zrobił, ale nie zakazywały także np. porywania pracowników Facebooka w celu uzyskania od nich haseł dostępu…

Także zachowanie Aleksa Stamosa budzi nasze zdziwienie. Bez wątpienia mógł być poirytowany zachowaniem Wesa, lecz nie usprawiedliwia to wywierania na niego nacisku przez przełożonych bez próby wcześniejszej rozmowy z samym zainteresowanym. Rozumiemy, że mając taką możliwość, Alex po prostu wybrał numer do szefa Wesa, jednak w ten sposób również przekroczył granicę przyzwoitości. Pozostaje mieć nadzieję, że wszyscy czegoś się z tej historii nauczą i kolejni testerzy będą wiedzieli, kiedy testy skończyć, a Facebook sprecyzuje zasady programu bug bounty i będzie łagodniejszy w swoich reakcjach.