Az - Function Apps
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure Functions to rozwiązanie bezserwerowe, które pozwala pisać mniej kodu, utrzymywać mniej infrastruktury i oszczędzać na kosztach. Zamiast martwić się o wdrażanie i utrzymanie serwerów, infrastruktura chmurowa zapewnia wszystkie aktualne zasoby potrzebne do utrzymania aplikacji w działaniu.
W portalu Azure integracja między Azure Functions a Azure API Management jest ułatwiona, co pozwala na ujawnienie punktów końcowych funkcji wyzwalanych przez HTTP jako interfejsów REST API. API ujawnione w ten sposób są opisane za pomocą definicji OpenAPI, co zapewnia standardowy, niezależny od języka interfejs do interfejsów RESTful.
Plan Flex Consumption oferuje dynamiczne, oparte na zdarzeniach skalowanie z elastycznymi opcjami obliczeniowymi. Automatycznie dodaje lub usuwa instancje funkcji w zależności od popytu, zapewniając efektywne wykorzystanie zasobów i opłacalność dzięki modelowi płać w miarę korzystania. Ten plan obsługuje wirtualne sieci dla zwiększonego bezpieczeństwa i pozwala na zmniejszenie zimnych startów poprzez wstępne przydzielanie instancji. Jest idealny dla aplikacji, które doświadczają zmiennych obciążeń i wymagają szybkiego skalowania bez potrzeby wsparcia kontenerów.
Tradycyjny plan Consumption dla Azure Functions to domyślna opcja hostingu bezserwerowego, w której płacisz tylko za zasoby obliczeniowe, gdy twoje funkcje są uruchomione. Automatycznie skaluje się w zależności od liczby nadchodzących zdarzeń, co czyni go bardzo opłacalnym dla aplikacji o przerywanym lub nieprzewidywalnym obciążeniu. Chociaż nie obsługuje wdrożeń kontenerowych, zawiera optymalizacje mające na celu skrócenie czasów zimnego startu i jest odpowiedni dla szerokiego zakresu aplikacji bezserwerowych, które wymagają automatycznego skalowania bez obciążenia zarządzania infrastrukturą.
Plan Premium dla Azure Functions jest zaprojektowany dla aplikacji, które potrzebują stałej wydajności i zaawansowanych funkcji. Automatycznie skaluje się w zależności od popytu, korzystając z wstępnie podgrzanych pracowników, eliminując zimne starty i zapewniając, że funkcje działają szybko nawet po okresach bezczynności. Ten plan oferuje potężniejsze instancje, wydłużone czasy wykonania i obsługuje łączność z wirtualną siecią. Dodatkowo pozwala na użycie niestandardowych obrazów Linux, co czyni go odpowiednim dla aplikacji krytycznych, które wymagają wysokiej wydajności i większej kontroli nad zasobami.
Plan Dedicated, znany również jako plan App Service, uruchamia twoje funkcje na dedykowanych maszynach wirtualnych w środowisku App Service. Ten plan zapewnia przewidywalne rozliczenia i pozwala na ręczne lub automatyczne skalowanie instancji, co czyni go idealnym dla scenariuszy długoterminowych, w których Durable Functions nie są odpowiednie. Obsługuje uruchamianie wielu aplikacji webowych i funkcji w tym samym planie, oferuje większe rozmiary obliczeniowe i zapewnia pełną izolację obliczeniową oraz bezpieczny dostęp do sieci poprzez Środowiska App Service (ASE). Ta opcja jest najlepsza dla aplikacji, które potrzebują stałej alokacji zasobów i rozbudowanej personalizacji.
Container Apps umożliwiają wdrażanie konteneryzowanych aplikacji funkcji w w pełni zarządzanym środowisku hostowanym przez Azure Container Apps. Ta opcja jest idealna do budowania aplikacji bezserwerowych opartych na zdarzeniach, które działają obok innych mikroserwisów, API i przepływów pracy. Obsługuje pakowanie niestandardowych bibliotek z kodem funkcji, migrację aplikacji dziedzicznych do mikroserwisów natywnych w chmurze oraz wykorzystanie zaawansowanej mocy obliczeniowej z zasobami GPU. Container Apps upraszczają wdrażanie, eliminując potrzebę zarządzania klastrami Kubernetes, co czyni je idealnymi dla deweloperów poszukujących elastyczności i skalowalności w konteneryzowanym środowisku.
Podczas tworzenia nowej aplikacji funkcji, która nie jest konteneryzowana (ale dostarcza kod do uruchomienia), kod i inne dane związane z funkcją będą przechowywane w koncie pamięci. Domyślnie konsola internetowa utworzy nową dla każdej funkcji, aby przechować kod.
Ponadto, gdy nowa instancja aplikacji musi być uruchomiona, kod aplikacji będzie zbierany stąd i wykonywany.
To jest bardzo interesujące z perspektywy atakującego, ponieważ dostęp do zapisu w tym koszyku pozwoli atakującemu na kompromitację kodu i eskalację uprawnień do zarządzanych tożsamości wewnątrz aplikacji funkcji.
Możliwe jest udzielenie dostępu do funkcji wszystkim użytkownikom Internetu bez wymagania jakiejkolwiek autoryzacji lub udzielenie dostępu na podstawie IAM.
Możliwe jest również udzielenie lub ograniczenie dostępu do aplikacji funkcji z Internetu, udzielając dostępu do wewnętrznej sieci (VPC) do aplikacji funkcji.
To jest bardzo interesujące z perspektywy atakującego, ponieważ może być możliwe przejście do wewnętrznych sieci z podatnej funkcji Lambda wystawionej na Internet.
Ponadto aplikacja funkcji może mieć pewne punkty końcowe, które wymagają określonego poziomu autoryzacji, takich jak "admin" lub "anonimowy". Atakujący może spróbować uzyskać dostęp do dozwolonych punktów końcowych anonimowych, aby obejść ograniczenia i uzyskać dostęp do wrażliwych danych lub funkcjonalności.
Należy zauważyć, że nie ma uprawnień RBAC, aby udzielić użytkownikom dostępu do wywoływania funkcji. Wywołanie funkcji zależy od wyzwalacza wybranego podczas jej tworzenia, a jeśli wybrano wyzwalacz HTTP, może być konieczne użycie klucza dostępu.
Podczas tworzenia punktu końcowego wewnątrz funkcji za pomocą wyzwalacza HTTP możliwe jest wskazanie poziomu autoryzacji klucza dostępu potrzebnego do wywołania funkcji. Dostępne są trzy opcje:
ANONIMOWY: Każdy może uzyskać dostęp do funkcji za pomocą URL.
FUNKCJA: Punkt końcowy jest dostępny tylko dla użytkowników korzystających z klucza funkcji, hosta lub klucza głównego.
ADMIN: Punkt końcowy jest dostępny tylko dla użytkowników z kluczem głównym.
Rodzaje kluczy:
Klucze funkcji: Klucze funkcji mogą być domyślne lub zdefiniowane przez użytkownika i są zaprojektowane w celu przyznania dostępu wyłącznie do konkretnych punktów końcowych funkcji w aplikacji funkcji. Umożliwia to precyzyjną kontrolę bezpieczeństwa, zapewniając, że tylko autoryzowani użytkownicy lub usługi mogą wywoływać konkretne funkcje bez narażania całej aplikacji.
Klucze hosta: Klucze hosta, które mogą być również domyślne lub zdefiniowane przez użytkownika, zapewniają dostęp do wszystkich punktów końcowych funkcji w aplikacji funkcji. Jest to przydatne, gdy wiele funkcji musi być dostępnych za pomocą jednego klucza, co upraszcza zarządzanie i zmniejsza liczbę kluczy, które muszą być dystrybuowane lub przechowywane w sposób bezpieczny.
Klucz główny: Klucz główny (_master) służy jako klucz administracyjny, który oferuje podwyższone uprawnienia, w tym dostęp do interfejsów API REST czasu wykonywania aplikacji funkcji. Ten klucz nie może być cofnięty i powinien być traktowany z najwyższą ostrożnością. Ważne jest, aby nie udostępniać klucza głównego osobom trzecim ani nie umieszczać go w natywnych aplikacjach klienckich, aby zapobiec nieautoryzowanemu dostępowi administracyjnemu.
Ustawiając autoryzację funkcji na ADMIN (a nie ANONIMOWY lub FUNKCJA), konieczne jest użycie tego klucza.
Klucze systemowe: Klucze systemowe są zarządzane przez konkretne rozszerzenia i są wymagane do uzyskania dostępu do punktów końcowych webhooków używanych przez wewnętrzne komponenty. Przykłady obejmują wyzwalacz Event Grid i Durable Functions, które wykorzystują klucze systemowe do bezpiecznej interakcji z ich odpowiednimi interfejsami API. Klucze systemowe mogą być regenerowane za pośrednictwem portalu Azure lub interfejsów API kluczy w celu utrzymania bezpieczeństwa.
Przykład dostępu do punktu końcowego API funkcji za pomocą klucza:
https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
