Podatności w Microsoft Azure App Services

Badacze z organizacji Intezer ujawnili dwie luki usług aplikacji hostingowej Microsoft Azure – „App Services”, które odpowiednio wykorzystane mogą umożliwić atakującemu przejęcie serwerów administracyjnych.

Azure App Services to usługa oparta na protokole HTTP do hostowania aplikacji internetowych i jest dostępna zarówno w chmurze Microsoft Azure, jak i w instalacjach lokalnych. Specjaliści odkryli dwie podatności w usłudze chmurowej, które mają szczególny wpływ na serwery Linux.

Jeśli atakujący z powodzeniem wykorzysta i połączy obydwie luki umożliwi mu to sfałszowanie żądań SSRF lub zdalne wykonywanie kodu w usłudze Azure App Service, co daje możliwość przejęcia serwera administracyjnego usługi Azure App Service.

Obie wady zostały odkryte trzy miesiące temu i zgłoszone firmie Microsoft. Luki nie mają klasyfikacji CVE.

Autor: Kapitan Hack Data dodania: 15 paź 2020 08:00 4 min czytania

Opis podatności

Pierwsza wada wynika z projektu open source o nazwie KuduLite w Azure App Services. To projekt oparty na Linux, który zarządza stroną administracyjną używaną do rejestrowania adminów w planie usługi App Service (aby rozpocząć korzystanie z usług aplikacji, użytkownik musi najpierw utworzyć plan usługi aplikacji). Po odkryciu, że usługa SSH instancji KuduLite używa zakodowanych na stałe poświadczeń „root: Docker!”, badacze mogli bez wysiłku zalogować się jako root. Po przejęciu kontroli nad instancją KuduLite badacze byli w stanie przejąć kontrolę nad serwerem sieciowym Software Configuration Management (SCM), który zarządza zmianami w dokumentach i kodach oraz kontroluje je podczas cyklu życia oprogramowania. Pozwoliło to następnie nasłuchiwać żądań HTTP użytkowników kierowanych na stronę internetową SCM, dodawać własne strony i umieszczać złośliwy kod JavaScript na stronie internetowej użytkownika. Użytkownik może również pozwolić App Services zarządzać serwerem git. Osoba atakująca może następnie dodać złośliwy kod do repozytorium, aby rozprzestrzenić się na inne instancje przy użyciu tego samego serwera git.

Druga podatność istnieje w KuduLite API. Problem wynika z tego, że węzeł aplikacji jest w stanie wysyłać żądania do KuduLite API bez weryfikacji dostępu – błąd, który jest szczególnie problematyczny, gdy rozważa się aplikację internetową z luką w zabezpieczeniach SSRF. Osoba atakująca, której uda się sfałszować żądanie GET, może uzyskać dostęp do systemu plików węzła aplikacji za pośrednictwem interfejsu API KuduLite VFS. Umożliwia to atakującemu łatwą kradzież kodu źródłowego i innych zasobów w węźle aplikacji. Osoba atakująca, której uda się sfałszować żądanie POST, może w międzyczasie wykonać zdalne kod w węźle aplikacji za pośrednictwem interfejsu API. W systemie Windows (gdzie używany jest Kudu) pakiety wysyłane z węzła aplikacji do węzła zarządzania są odrzucane.

Te dwie luki można połączyć w łańcuch ataku, ponieważ gdy atakujący osiągnie możliwość zdalnego wykonania kodu może następnie wykorzystać pierwszą podatność. Jeden z potencjalnych wektorów ataku polega na tym, że osoba atakująca może wykorzystać tę lukę do wszczepienia strony phishingowej na rzekomo stronę internetową SCM (jak widać na poniższym filmie):

Podsumowanie

Bezpieczeństwo w chmurze jest wciąż stosunkowo nowe, co sprawia, że badanie i dokumentowanie nowych możliwości ataków, które pojawiają się podczas korzystania z tych usług, ma zasadnicze znaczenie.

Zgodnie z ogólną najlepszą praktyką, bezpieczeństwo środowiska wykonawczego w chmurze, czyli zdalnych API oraz linii poleceń, jest ważną linią obrony i jednym z pierwszych działań, które należy podjąć, aby zmniejszyć ryzyko ataków na serwery w chmurze.