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 Function Apps - це безсерверна обчислювальна служба, яка дозволяє запускати невеликі фрагменти коду, звані функціями, без управління підлягаючою інфраструктурою. Вони призначені для виконання коду у відповідь на різні тригери, такі як HTTP запити, таймери або події з інших служб Azure, таких як Blob Storage або Event Hubs. Function Apps підтримують кілька мов програмування, включаючи C#, Python, JavaScript і Java, що робить їх універсальними для створення додатків, орієнтованих на події, автоматизації робочих процесів або інтеграції служб. Вони є економічно вигідними, оскільки зазвичай ви платите лише за час обчислень, коли ваш код виконується.
Зверніть увагу, що Functions є підмножиною App Services, тому багато функцій, обговорюваних тут, також будуть використовуватися додатками, створеними як Azure Apps (webapp в cli).
Flex Consumption Plan: Пропонує динамічне, орієнтоване на події масштабування з оплатою за фактом використання, додаючи або видаляючи екземпляри функцій залежно від попиту. Підтримує віртуальну мережу та попередньо підготовлені екземпляри, щоб зменшити холодні старти, що робить його підходящим для змінних навантажень, які не потребують підтримки контейнерів.
Traditional Consumption Plan: За замовчуванням безсерверний варіант, де ви платите лише за обчислювальні ресурси, коли функції виконуються. Автоматично масштабується на основі вхідних подій і включає оптимізації холодного старту, але не підтримує розгортання контейнерів. Ідеально підходить для періодичних навантажень, які потребують автоматичного масштабування.
Premium Plan: Призначений для послідовної продуктивності, з попередньо прогрітими працівниками, щоб усунути холодні старти. Пропонує подовжені часи виконання, віртуальну мережу та підтримує кастомізовані образи Linux, що робить його ідеальним для додатків критичного призначення, які потребують високої продуктивності та розширених функцій.
Dedicated Plan: Виконується на виділених віртуальних машинах з передбачуваним білінгом і підтримує ручне або автоматичне масштабування. Дозволяє запускати кілька додатків на одному плані, забезпечує ізоляцію обчислень і гарантує безпечний доступ до мережі через App Service Environments, що робить його ідеальним для додатків з тривалим виконанням, які потребують послідовного виділення ресурсів.
Container Apps: Дозволяє розгортати контейнеризовані функціональні додатки в керованому середовищі, поряд з мікросервісами та API. Підтримує кастомні бібліотеки, міграцію старих додатків і обробку GPU, усуваючи управління кластерами Kubernetes. Ідеально підходить для додатків, орієнтованих на події, масштабованих контейнеризованих додатків.
Коли створюється новий Function App, не контейнеризований (але надається код для виконання), код та інші дані, пов'язані з функцією, будуть зберігатися в обліковому записі Storage. За замовчуванням веб-консоль створить новий обліковий запис для кожної функції для зберігання коду.
Більше того, модифікуючи код всередині кошика (в різних форматах, в яких він може бути збережений), код програми буде змінено на новий і виконано наступного разу, коли функція буде викликана.
Це дуже цікаво з точки зору атакуючого, оскільки доступ на запис до цього кошика дозволить атакуючому компрометувати код і підвищити привілеї до керованих ідентичностей всередині Function App.
Більше про це в розділі підвищення привілеїв.
Також можливо знайти ключі майстра та функцій, збережені в обліковому записі зберігання в контейнері azure-webjobs-secrets всередині папки <app-name> у JSON-файлах, які ви можете знайти всередині.
Зверніть увагу, що функції також дозволяють зберігати код у віддаленому місці, просто вказуючи URL на нього.
Використовуючи HTTP тригер:
Можливо надати доступ до функції з усієї Інтернету без вимоги будь-якої аутентифікації або надати доступ на основі IAM. Хоча також можливо обмежити цей доступ.
Також можливо надати або обмежити доступ до Function App з внутрішньої мережі (VPC).
Це дуже цікаво з точки зору атакуючого, оскільки може бути можливим перехід до внутрішніх мереж з вразливої функції, відкритої для Інтернету.
Можливо налаштувати змінні середовища всередині програми, які можуть містити чутливу інформацію. Більше того, за замовчуванням змінні середовища AzureWebJobsStorage та WEBSITE_CONTENTAZUREFILECONNECTIONSTRING (серед інших) створюються. Ці змінні особливо цікаві, оскільки містять ключ облікового запису для контролю з ПОВНИМИ правами доступу до облікового запису зберігання, що містить дані програми. Ці налаштування також потрібні для виконання коду з облікового запису зберігання.
Ці змінні середовища або параметри конфігурації також контролюють, як функція виконує код, наприклад, якщо WEBSITE_RUN_FROM_PACKAGE існує, це вказує на URL, де розташований код програми.
Всередині linux пісочниці вихідний код розташований у /home/site/wwwroot у файлі function_app.py (якщо використовується python), користувач, що виконує код, - app (без прав sudo).
У Windows функції, що використовує NodeJS, код розташовувався у C:\home\site\wwwroot\HttpTrigger1\index.js, ім'я користувача було mawsFnPlaceholder8_f_v4_node_20_x86 і він був частиною груп: Mandatory Label\High Mandatory Level Label, Everyone, BUILTIN\Users, NT AUTHORITY\INTERACTIVE, CONSOLE LOGON, NT AUTHORITY\Authenticated Users, NT AUTHORITY\This Organization, BUILTIN\IIS_IUSRS, LOCAL, 10-30-4-99\Dwas Site Users.
Так само, як і VMs, функції можуть мати керовані ідентичності двох типів: системно призначені та призначені користувачем.
Системно призначена ідентичність буде керованою ідентичністю, яку тільки функція, якій вона призначена, зможе використовувати, тоді як призначені користувачем керовані ідентичності - це керовані ідентичності, які будь-яка інша служба Azure зможе використовувати.
Так само, як і в VMs, функції можуть мати 1 системно призначену керовану ідентичність і кілька призначених користувачем, тому завжди важливо намагатися знайти всі з них, якщо ви компрометуєте функцію, оскільки ви можете підвищити привілеї до кількох керованих ідентичностей з однієї функції.
Якщо не використовується системно призначена ідентичність, але одна або кілька призначених користувачем ідентичностей прикріплені до функції, за замовчуванням ви не зможете отримати жоден токен.
Можливо використовувати PEASS скрипти для отримання токенів з за замовчуванням керованої ідентичності з кінцевої точки метаданих. Або ви можете отримати їх вручну, як пояснено в:
Зверніть увагу, що вам потрібно знайти спосіб перевірити всі керовані ідентичності, прикріплені до функції, оскільки якщо ви цього не вкажете, кінцева точка метаданих використовуватиме лише за замовчуванням (перевірте попереднє посилання для отримання додаткової інформації).
Зверніть увагу, що немає дозволів RBAC для надання доступу користувачам для виклику функцій. Виклик функції залежить від тригера, вибраного під час її створення, і якщо був вибраний HTTP тригер, можливо, знадобиться використовувати ключ доступу.
Коли створюється кінцева точка всередині функції, використовуючи HTTP тригер, можливо вказати рівень авторизації ключа доступу, необхідний для активації функції. Доступні три варіанти:
ANONYMOUS: Кожен може отримати доступ до функції за URL.
FUNCTION: Кінцева точка доступна лише користувачам, які використовують ключ функції, хоста або майстра.
ADMIN: Кінцева точка доступна лише користувачам з ключем майстра.
Типи ключів:
Function Keys: Ключі функцій можуть бути або за замовчуванням, або визначеними користувачем і призначені для надання доступу виключно до конкретних кінцевих точок функцій в рамках Function App, що дозволяє більш детальний доступ до кінцевих точок.
Host Keys: Ключі хоста, які також можуть бути за замовчуванням або визначеними користувачем, надають доступ до всіх кінцевих точок функцій в рамках Function App з рівнем доступу FUNCTION.
Master Key: Ключ майстра (_master) служить адміністративним ключем, який пропонує підвищені права, включаючи доступ до всіх кінцевих точок функцій (включаючи рівень доступу ADMIN). Цей ключ не може бути відкликаний.
System Keys: Системні ключі керуються конкретними розширеннями і потрібні для доступу до кінцевих точок вебхуків, які використовуються внутрішніми компонентами. Прикладами є тригер Event Grid і Durable Functions, які використовують системні ключі для безпечної взаємодії зі своїми відповідними API.
Example to access a function API endpoint using a key:
https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>
Так само, як і в App Services, функції також підтримують базову аутентифікацію для підключення до SCM та FTP для розгортання коду, використовуючи ім'я користувача та пароль в URL, наданому Azure. Більше інформації про це в:
Коли функція генерується з репозиторію Github, веб-консоль Azure дозволяє автоматично створити робочий процес Github у конкретному репозиторії, тому що щоразу, коли цей репозиторій оновлюється, код функції оновлюється. Насправді YAML дії Github для функції Python виглядає так:
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
