Dziury w Pockecie, czyli jak łatwo zhakować aplikację w chmurze

8 lat historii i kilkanaście milionów użytkowników mogą sugerować, że aplikacja jest już dojrzała i solidnie przetestowana. Nie zawsze jest to jednak prawdą, a śmiesznie trywialne i niebezpieczne błędy mogą ciągle czekać na odkrycie.

Powstała w roku 2007 pod nazwą Read it Later aplikacja Pocket rządzi dzisiaj na rynku narzędzi umożliwiających pobranie wybranych artykułów i zapisanie ich w celu późniejszej lektury. Mimo iż jej działaniu na pewno przyglądał się niejeden badacz, to Clint Ruoho odkrył metodę przejęcia serwerów firmy przez zestaw naprawdę prostych błędów.

Pobierz linka

Jednym z pierwszych etapów rozpoznania potencjalnych podatności serwera jest weryfikacja znanych adresów, mogących dostarczyć dodatkowych informacji o jego działaniu. Jednym z nich jest usługa statystyk Apache kryjących się z reguły pod linkiem /server-status. Często można w niej wyczytać ciekawe informacje (np. na serwerach Empiku pozwalała na poznanie danych klientów), jednak serwery Pocketa informowały, że choć usługa jest włączona, to jest niedostępna dla internautów. Kiedy jednak pomyślimy, że testujemy usługę pobierania linków z internetu, może warto sprawdzić, co stanie się, gdy do kolejki dodamy

http://127.0.0.1/server-status

Jak się zapewne już domyślacie, serwer Pocketa grzecznie pobrał żądany plik i zaserwował go badaczowi. Dzięki temu można było poznać wewnętrzną adresację infrastruktury używanej przez Pocketa (a także np. podglądać aktywność jego użytkowników). Z kolei próby wczytania takich linków jak

file:///etc/passwd
ssh://localhost
telnet://localhost:25

nie dały żadnego rezultatu. Kiedy jednak badacz zorientował się, że Pocket korzysta z infrastruktury chmury Amazona, dodał do kolejki pobierania linki specyficzne dla tej usługi, czyli:

http://169.254.169.254/latest/meta-data/
http://169.254.169.254/latest/meta-data/hostname
http://169.254.169.254/latest/meta-data/ami-id

Linki zadziały i można w nich było znaleźć sporo technicznych szczegółów konfiguracyjnych (strefa, rodzaj instancji, rodzaj połączeń sieciowych i podłączonych usług przechowywania danych, adresy MAC itp.). Ciągle jednak brak było możliwości uzyskania zdalnego dostępu do serwerów.

Pocket

Skoro link nie działa…

Korzystając z odkrytych już problemów atakujący mógł np. przeskanować usługi HTTP na serwerze lokalnym omijając reguły firewalla, zidentyfikować dostępne aplikacje i atakować je udając lokalnego użytkownika. Czemu jednak nie spróbować czegoś bardziej zuchwałego? Skoro zakolejkowanie  file:///etc/passwd nie działało, to ciekawe jak serwer zachowa się gdy link dodany do kolejki wskaże na serwer, który odpowie odpowiednim błędem 301.

HTTP/1.1 301 Moved Permanently
Location: file:///etc/passwd
Content-Length: 52
Date: Tue, 28 Jul 2015 18:42:58 GMT
Connection: keep-alive

Moved Permanently. Redirecting to file:///etc/passwd

Wyobrażamy sobie zdziwienie na twarzy badacza, gdy w swojej aplikacji znalazł zawartość pliku /etc/passwd pobranego z serwera Pocketa. A pomyślcie, jaka była jego reakcja, gdy sprawdził, że może pobrać dowolny plik z serwera, ponieważ proces działa na uprawnieniach roota.

Scenariusz całego ataku mógł zatem wyglądać następująco:

• przez /server-status poznajemy prywatną adresację serwerów
• przez 301 pobieramy /etc/passwd i poznajemy listę użytkowników
• przez 301 pobieramy klucz prywatny SSH wybranego użytkownika
• uruchamiamy instancję serwera w tej samej strefie, dostając dostęp do tej samej prywatnej adresacji
• logujemy się na serwer

To oczywiście tylko przykład – prawdopodobnych możliwości ataku było znacznie więcej. Pocket szybko błędy załatał, pytanie jednak, jakie jeszcze czekają na odkrycie. Co ciekawe, bardzo podobne błędy odnaleziono już rok temu w Prezi.