Az - Function Apps
Last updated
Last updated
Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Azure Functions ist eine serverlose Lösung, die es Ihnen ermöglicht, weniger Code zu schreiben, weniger Infrastruktur zu warten und Kosten zu sparen. Anstatt sich um das Bereitstellen und Warten von Servern zu kümmern, stellt die Cloud-Infrastruktur alle aktuellen Ressourcen bereit, die benötigt werden, um Ihre Anwendungen am Laufen zu halten.
Im Azure-Portal wird die Integration zwischen Azure Functions und Azure API Management erleichtert, sodass HTTP-Trigger-Funktionsendpunkte als REST-APIs exponiert werden können. Die auf diese Weise exponierten APIs werden mit einer OpenAPI-Definition beschrieben, die eine standardisierte, sprachunabhängige Schnittstelle zu RESTful APIs bietet.
Der Flex Consumption Plan bietet dynamisches, ereignisgesteuertes Skalieren mit flexiblen Rechenoptionen. Er fügt automatisch Funktionsinstanzen basierend auf der Nachfrage hinzu oder entfernt sie, um eine effiziente Ressourcennutzung und Kosteneffektivität durch ein Pay-as-you-go-Modell zu gewährleisten. Dieser Plan unterstützt virtuelles Networking für verbesserte Sicherheit und ermöglicht es Ihnen, Kaltstarts durch die Vorabbereitstellung von Instanzen zu reduzieren. Er ist ideal für Anwendungen, die variable Arbeitslasten aufweisen und eine schnelle Skalierung ohne Containerunterstützung erfordern.
Der traditionelle Consumption Plan für Azure Functions ist die standardmäßige serverlose Hosting-Option, bei der Sie nur für die Rechenressourcen bezahlen, wenn Ihre Funktionen ausgeführt werden. Er skaliert automatisch basierend auf der Anzahl der eingehenden Ereignisse, was ihn sehr kosteneffektiv für Anwendungen mit intermittierenden oder unvorhersehbaren Arbeitslasten macht. Während er keine Containerbereitstellungen unterstützt, umfasst er Optimierungen zur Reduzierung der Kaltstartzeiten und ist für eine Vielzahl von serverlosen Anwendungen geeignet, die automatisches Skalieren ohne den Aufwand der Infrastrukturverwaltung erfordern.
Der Premium Plan für Azure Functions ist für Anwendungen konzipiert, die konsistente Leistung und erweiterte Funktionen benötigen. Er skaliert automatisch basierend auf der Nachfrage mit vorgewärmten Arbeitern, wodurch Kaltstarts eliminiert werden und sichergestellt wird, dass Funktionen auch nach Inaktivitätsphasen umgehend ausgeführt werden. Dieser Plan bietet leistungsstärkere Instanzen, verlängerte Ausführungszeiten und unterstützt die Verbindung zu virtuellen Netzwerken. Darüber hinaus ermöglicht er die Verwendung benutzerdefinierter Linux-Images, was ihn für geschäftskritische Anwendungen geeignet macht, die hohe Leistung und mehr Kontrolle über Ressourcen erfordern.
Der Dedicated Plan, auch bekannt als App Service Plan, führt Ihre Funktionen auf dedizierten virtuellen Maschinen innerhalb einer App Service-Umgebung aus. Dieser Plan bietet vorhersehbare Abrechnung und ermöglicht manuelles oder automatisches Skalieren von Instanzen, was ihn ideal für lang laufende Szenarien macht, in denen Durable Functions nicht geeignet sind. Er unterstützt das Ausführen mehrerer Web- und Funktionsanwendungen im selben Plan, bietet größere Rechenkapazitäten und gewährleistet vollständige Rechenisolierung und sicheren Netzwerkzugang über App Service Environments (ASE). Diese Option ist am besten für Anwendungen geeignet, die eine konsistente Ressourcenzuteilung und umfangreiche Anpassungsmöglichkeiten benötigen.
Container Apps ermöglichen es Ihnen, containerisierte Funktionsanwendungen innerhalb einer vollständig verwalteten Umgebung zu implementieren, die von Azure Container Apps gehostet wird. Diese Option ist perfekt für den Aufbau von ereignisgesteuerten, serverlosen Anwendungen, die neben anderen Mikrodiensten, APIs und Workflows ausgeführt werden. Sie unterstützt das Verpacken benutzerdefinierter Bibliotheken mit Ihrem Funktionscode, die Migration von Legacy-Anwendungen zu cloud-nativen Mikrodiensten und die Nutzung leistungsstarker Verarbeitungskapazitäten mit GPU-Ressourcen. Container Apps vereinfachen die Bereitstellung, indem sie die Notwendigkeit zur Verwaltung von Kubernetes-Clustern beseitigen, was sie ideal für Entwickler macht, die Flexibilität und Skalierbarkeit in einer containerisierten Umgebung suchen.
Beim Erstellen einer neuen Funktionsanwendung, die nicht containerisiert ist (aber den auszuführenden Code bereitstellt), werden der Code und andere funktionsbezogene Daten in einem Speicherkonto gespeichert. Standardmäßig erstellt die Webkonsole für jede Funktion ein neues Konto, um den Code zu speichern.
Darüber hinaus wird, wann immer eine neue Instanz der Anwendung ausgeführt werden muss, der Code der Anwendung von hier abgerufen und ausgeführt.
Dies ist aus der Perspektive eines Angreifers sehr interessant, da Schreibzugriff auf diesen Bucket einem Angreifer ermöglichen würde, den Code zu kompromittieren und Berechtigungen für die verwalteten Identitäten innerhalb der Funktionsanwendung zu eskalieren.
Es ist möglich, einer Funktion den Zugriff auf das gesamte Internet zu gewähren, ohne eine Authentifizierung zu verlangen, oder den Zugriff IAM-basiert zu gewähren.
Es ist auch möglich, den Zugriff auf die Funktionsanwendung aus dem Internet zu gewähren oder einzuschränken und den Zugriff auf ein internes Netzwerk (VPC) zur Funktionsanwendung zu gewähren.
Dies ist aus der Perspektive eines Angreifers sehr interessant, da es möglich sein könnte, auf interne Netzwerke zu pivotieren von einer verwundbaren Lambda-Funktion, die dem Internet ausgesetzt ist.
Darüber hinaus kann die Funktionsanwendung bestimmte Endpunkte haben, die ein gewisses Maß an Authentifizierung erfordern, wie "admin" oder "anonym". Ein Angreifer könnte versuchen, auf die anonym erlaubten Endpunkte zuzugreifen, um die Einschränkungen zu umgehen und Zugriff auf sensible Daten oder Funktionen zu erhalten.
Bitte beachten Sie, dass es keine RBAC-Berechtigungen gibt, um Benutzern den Zugriff auf die Funktionen zu gewähren. Der Funktionsaufruf hängt vom Trigger ab, der bei der Erstellung ausgewählt wurde, und wenn ein HTTP-Trigger ausgewählt wurde, könnte es erforderlich sein, einen Zugriffsschlüssel zu verwenden.
Beim Erstellen eines Endpunkts innerhalb einer Funktion mit einem HTTP-Trigger ist es möglich, das Autorisierungsniveau des Zugriffsschlüssels anzugeben, das erforderlich ist, um die Funktion auszulösen. Drei Optionen stehen zur Verfügung:
ANONYMOUS: Jeder kann über die URL auf die Funktion zugreifen.
FUNCTION: Der Endpunkt ist nur für Benutzer zugänglich, die einen Funktions-, Host- oder Master-Schlüssel verwenden.
ADMIN: Der Endpunkt ist nur für Benutzer mit einem Master-Schlüssel zugänglich.
Arten von Schlüsseln:
Funktionsschlüssel: Funktionsschlüssel können entweder Standard- oder benutzerdefiniert sein und sind dafür ausgelegt, den Zugriff ausschließlich auf bestimmte Funktionsendpunkte innerhalb einer Funktionsanwendung zu gewähren. Dies ermöglicht eine feingranulare Sicherheitskontrolle, die sicherstellt, dass nur autorisierte Benutzer oder Dienste bestimmte Funktionen aufrufen können, ohne die gesamte Anwendung offenzulegen.
Host-Schlüssel: Host-Schlüssel, die ebenfalls Standard- oder benutzerdefiniert sein können, gewähren Zugriff auf alle Funktionsendpunkte innerhalb einer Funktionsanwendung. Dies ist nützlich, wenn mehrere Funktionen mit einem einzigen Schlüssel aufgerufen werden müssen, was die Verwaltung vereinfacht und die Anzahl der Schlüssel reduziert, die verteilt oder sicher gespeichert werden müssen.
Master-Schlüssel: Der Master-Schlüssel (_master) dient als administrativer Schlüssel, der erweiterte Berechtigungen bietet, einschließlich Zugriff auf die Runtime-REST-APIs einer Funktionsanwendung. Dieser Schlüssel kann nicht widerrufen werden und sollte mit äußerster Vorsicht behandelt werden. Es ist entscheidend, den Master-Schlüssel nicht mit Dritten zu teilen oder in nativen Client-Anwendungen einzuschließen, um unbefugten administrativen Zugriff zu verhindern.
Bei der Festlegung der Authentifizierung einer Funktion auf ADMIN (und nicht ANONYMOUS oder FUNCTION) ist es erforderlich, diesen Schlüssel zu verwenden.
Systemschlüssel: Systemschlüssel werden von bestimmten Erweiterungen verwaltet und sind erforderlich, um auf Webhook-Endpunkte zuzugreifen, die von internen Komponenten verwendet werden. Beispiele sind der Event Grid-Trigger und Durable Functions, die Systemschlüssel verwenden, um sicher mit ihren jeweiligen APIs zu interagieren. Systemschlüssel können über das Azure-Portal oder die Schlüssel-APIs regeneriert werden, um die Sicherheit aufrechtzuerhalten.
Beispiel für den Zugriff auf einen Funktions-API-Endpunkt mit einem Schlüssel:
https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>
Lerne & übe AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lerne & übe GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
