Podatności w Microsoft Azure App Services

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.