mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-01-15 14:23:16 -08:00
Translated ['.github/pull_request_template.md', 'src/README.md', 'src/pe
This commit is contained in:
@@ -2,37 +2,37 @@
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Basic Information
|
||||
## Основна інформація
|
||||
|
||||
**Azure Function Apps** - це **безсерверна обчислювальна служба**, яка дозволяє запускати невеликі фрагменти коду, звані **функціями**, без управління підлягаючою інфраструктурою. Вони призначені для виконання коду у відповідь на різні тригери, такі як **HTTP запити, таймери або події з інших служб Azure**, таких як Blob Storage або Event Hubs. Function Apps підтримують кілька мов програмування, включаючи C#, Python, JavaScript та Java, що робить їх універсальними для створення **додатків, орієнтованих на події**, автоматизації робочих процесів або інтеграції служб. Вони є економічно вигідними, оскільки зазвичай ви платите лише за час обчислень, коли ваш код виконується.
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що **Functions є підмножиною App Services**, тому багато функцій, обговорюваних тут, також будуть використовуватися додатками, створеними як Azure Apps (`webapp` в cli).
|
||||
|
||||
### Different Plans
|
||||
### Різні плани
|
||||
|
||||
- **Flex Consumption Plan**: Пропонує **динамічне, орієнтоване на події масштабування** з оплатою за фактом використання, додаючи або видаляючи екземпляри функцій залежно від попиту. Підтримує **віртуальну мережу** та **попередньо підготовлені екземпляри**, щоб зменшити холодні старти, що робить його підходящим для **змінних навантажень**, які не потребують підтримки контейнерів.
|
||||
- **Traditional Consumption Plan**: За замовчуванням безсерверний варіант, де ви **платите лише за обчислювальні ресурси, коли функції виконуються**. Автоматично масштабується на основі вхідних подій і включає **оптимізації холодного старту**, але не підтримує розгортання контейнерів. Ідеально підходить для **періодичних навантажень**, які потребують автоматичного масштабування.
|
||||
- **Premium Plan**: Призначений для **послідовної продуктивності**, з **попередньо прогрітими працівниками**, щоб усунути холодні старти. Пропонує **подовжені часи виконання, віртуальну мережу** та підтримує **кастомізовані образи Linux**, що робить його ідеальним для **додатків, критично важливих для місії**, які потребують високої продуктивності та розширених функцій.
|
||||
- **Dedicated Plan**: Виконується на виділених віртуальних машинах з **передбачуваним білінгом** і підтримує ручне або автоматичне масштабування. Дозволяє запускати кілька додатків на одному плані, забезпечує **ізоляцію обчислень** і гарантує **безпечний мережевий доступ** через App Service Environments, що робить його ідеальним для **додатків, що працюють тривалий час**, які потребують послідовного виділення ресурсів.
|
||||
- **Traditional Consumption Plan**: За замовчуванням безсерверний варіант, де ви **платите лише за обчислювальні ресурси, коли функції виконуються**. Він автоматично масштабується на основі вхідних подій і включає **оптимізації холодного старту**, але не підтримує розгортання контейнерів. Ідеально підходить для **періодичних навантажень**, які потребують автоматичного масштабування.
|
||||
- **Premium Plan**: Призначений для **послідовної продуктивності**, з **попередньо прогрітими працівниками**, щоб усунути холодні старти. Пропонує **подовжені часи виконання, віртуальну мережу** та підтримує **кастомізовані образи Linux**, що робить його ідеальним для **додатків критичного призначення**, які потребують високої продуктивності та розширених функцій.
|
||||
- **Dedicated Plan**: Виконується на виділених віртуальних машинах з **передбачуваним білінгом** і підтримує ручне або автоматичне масштабування. Дозволяє запускати кілька додатків на одному плані, забезпечує **ізоляцію обчислень** і гарантує **безпечний доступ до мережі** через App Service Environments, що робить його ідеальним для **додатків з тривалим виконанням**, які потребують послідовного виділення ресурсів.
|
||||
- **Container Apps**: Дозволяє розгортати **контейнеризовані функціональні додатки** в керованому середовищі, поряд з мікросервісами та API. Підтримує кастомні бібліотеки, міграцію спадкових додатків та **обробку GPU**, усуваючи управління кластерами Kubernetes. Ідеально підходить для **масштабованих контейнеризованих додатків, орієнтованих на події**.
|
||||
|
||||
### **Storage Buckets**
|
||||
### **Сховища**
|
||||
|
||||
Коли створюється новий Function App, не контейнеризований (але надається код для виконання), **код та інші дані, пов'язані з функцією, будуть зберігатися в обліковому записі Storage**. За замовчуванням веб-консоль створить новий обліковий запис для кожної функції для зберігання коду.
|
||||
При створенні нового Function App, який не контейнеризований (але надає код для виконання), **код та інші дані, пов'язані з функцією, будуть зберігатися в обліковому записі сховища**. За замовчуванням веб-консоль створить новий обліковий запис для кожної функції для зберігання коду.
|
||||
|
||||
Більше того, модифікуючи код всередині кошика (в різних форматах, в яких він може бути збережений), **код програми буде змінено на новий і виконано** наступного разу, коли функція буде викликана.
|
||||
Більше того, модифікуючи код всередині сховища (в різних форматах, в яких він може бути збережений), **код програми буде змінено на новий і виконано** наступного разу, коли функція буде викликана.
|
||||
|
||||
> [!CAUTION]
|
||||
> Це дуже цікаво з точки зору атакуючого, оскільки **доступ на запис до цього кошика** дозволить атакуючому **компрометувати код і підвищити привілеї** до керованих ідентичностей всередині Function App.
|
||||
> Це дуже цікаво з точки зору атакуючого, оскільки **доступ на запис до цього сховища** дозволить атакуючому **компрометувати код і підвищити привілеї** до керованих ідентичностей всередині Function App.
|
||||
>
|
||||
> Більше про це в **розділі підвищення привілеїв**.
|
||||
|
||||
Також можливо знайти **ключі майстра та функцій**, збережені в обліковому записі зберігання в контейнері **`azure-webjobs-secrets`** всередині папки **`<app-name>`** у JSON-файлах, які ви можете знайти всередині.
|
||||
Також можливо знайти **ключі майстра та функцій**, збережені в обліковому записі сховища в контейнері **`azure-webjobs-secrets`** всередині папки **`<app-name>`** у JSON-файлах, які ви можете знайти всередині.
|
||||
|
||||
Зверніть увагу, що функції також дозволяють зберігати код у віддаленому місці, просто вказуючи URL на нього.
|
||||
|
||||
### Networking
|
||||
### Мережа
|
||||
|
||||
Використовуючи HTTP тригер:
|
||||
|
||||
@@ -40,43 +40,43 @@
|
||||
- Також можливо **надати або обмежити доступ** до Function App з **внутрішньої мережі (VPC)**.
|
||||
|
||||
> [!CAUTION]
|
||||
> Це дуже цікаво з точки зору атакуючого, оскільки може бути можливим **перейти до внутрішніх мереж** з вразливої функції, виставленої в Інтернет.
|
||||
> Це дуже цікаво з точки зору атакуючого, оскільки може бути можливим **перемикання на внутрішні мережі** з вразливої функції, виставленої в Інтернет.
|
||||
|
||||
### **Function App Settings & Environment Variables**
|
||||
### **Налаштування Function App та змінні середовища**
|
||||
|
||||
Можливо налаштувати змінні середовища всередині програми, які можуть містити чутливу інформацію. Більше того, за замовчуванням створюються змінні середовища **`AzureWebJobsStorage`** та **`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING`** (серед інших). Ці змінні особливо цікаві, оскільки **містять ключ облікового запису для контролю з ПОВНИМИ правами доступу до облікового запису зберігання, що містить дані програми**. Ці налаштування також потрібні для виконання коду з облікового запису зберігання.
|
||||
Можливо налаштувати змінні середовища всередині програми, які можуть містити чутливу інформацію. Більше того, за замовчуванням змінні середовища **`AzureWebJobsStorage`** та **`WEBSITE_CONTENTAZUREFILECONNECTIONSTRING`** (серед інших) створюються. Ці змінні особливо цікаві, оскільки вони **містять ключ облікового запису для контролю з ПОВНИМИ правами доступу до облікового запису сховища, що містить дані програми**. Ці налаштування також потрібні для виконання коду з облікового запису сховища.
|
||||
|
||||
Ці змінні середовища або параметри конфігурації також контролюють, як функція виконує код, наприклад, якщо **`WEBSITE_RUN_FROM_PACKAGE`** існує, це вказує на URL, де розташований код програми.
|
||||
|
||||
### **Function Sandbox**
|
||||
### **Пісочниця функцій**
|
||||
|
||||
Всередині linux пісочниці вихідний код розташований у **`/home/site/wwwroot`** у файлі **`function_app.py`** (якщо використовується python), користувач, що виконує код, - **`app`** (без прав sudo).
|
||||
Всередині пісочниці 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`.
|
||||
|
||||
### **Managed Identities & Metadata**
|
||||
### **Керовані ідентичності та метадані**
|
||||
|
||||
Так само як і [**VMs**](vms/), функції можуть мати **керовані ідентичності** двох типів: системно призначені та призначені користувачем.
|
||||
Так само, як і [**VMs**](vms/), функції можуть мати **керовані ідентичності** двох типів: системно призначені та призначені користувачем.
|
||||
|
||||
**Системно призначена** ідентичність буде керованою ідентичністю, яку **тільки функція**, якій вона призначена, зможе використовувати, тоді як **призначені користувачем** керовані ідентичності - це керовані ідентичності, які **будь-яка інша служба Azure зможе використовувати**.
|
||||
|
||||
> [!NOTE]
|
||||
> Так само як і в [**VMs**](vms/), функції можуть мати **1 системно призначену** керовану ідентичність і **кілька призначених користувачем**, тому завжди важливо намагатися знайти всі з них, якщо ви компрометуєте функцію, оскільки ви можете підвищити привілеї до кількох керованих ідентичностей з однієї функції.
|
||||
> Так само, як і в [**VMs**](vms/), функції можуть мати **1 системно призначену** керовану ідентичність і **кілька призначених користувачем**, тому завжди важливо намагатися знайти всі з них, якщо ви компрометуєте функцію, оскільки ви можете підвищити привілеї до кількох керованих ідентичностей з однієї функції.
|
||||
>
|
||||
> Якщо не використовується системно призначена ідентичність, але одна або кілька призначених користувачем ідентичностей прикріплені до функції, за замовчуванням ви не зможете отримати жоден токен.
|
||||
> Якщо не використовується системно призначена керована ідентичність, але одна або кілька призначених користувачем ідентичностей прикріплені до функції, за замовчуванням ви не зможете отримати жоден токен.
|
||||
|
||||
Можливо використовувати [**PEASS скрипти**](https://github.com/peass-ng/PEASS-ng) для отримання токенів з за замовчуванням керованої ідентичності з кінцевої точки метаданих. Або ви можете отримати їх **вручну**, як пояснено в:
|
||||
|
||||
{% embed url="https://book.hacktricks.xyz/pentesting-web/ssrf-server-side-request-forgery/cloud-ssrf#azure-vm" %}
|
||||
|
||||
Зверніть увагу, що вам потрібно знайти спосіб **перевірити всі керовані ідентичності, прикріплені до функції**, оскільки якщо ви цього не вкажете, кінцева точка метаданих **використовуватиме лише за замовчуванням** (перевірте попереднє посилання для отримання додаткової інформації).
|
||||
Зверніть увагу, що вам потрібно знайти спосіб **перевірити всі керовані ідентичності, які функція має прикріпленими**, оскільки якщо ви цього не вкажете, кінцева точка метаданих **використовуватиме лише за замовчуванням** (перевірте попереднє посилання для отримання додаткової інформації).
|
||||
|
||||
## Access Keys
|
||||
## Ключі доступу
|
||||
|
||||
> [!NOTE]
|
||||
> Зверніть увагу, що немає дозволів RBAC для надання доступу користувачам для виклику функцій. **Виклик функції залежить від тригера**, вибраного під час її створення, і якщо був вибраний HTTP тригер, можливо, знадобиться використовувати **ключ доступу**.
|
||||
|
||||
Коли створюється кінцева точка всередині функції, використовуючи **HTTP тригер**, можливо вказати **рівень авторизації ключа доступу**, необхідний для активації функції. Доступні три варіанти:
|
||||
При створенні кінцевої точки всередині функції за допомогою **HTTP тригера** можливо вказати **рівень авторизації ключа доступу**, необхідний для виклику функції. Доступні три варіанти:
|
||||
|
||||
- **ANONYMOUS**: **Кожен** може отримати доступ до функції за URL.
|
||||
- **FUNCTION**: Кінцева точка доступна лише користувачам, які використовують **ключ функції, хоста або майстра**.
|
||||
@@ -84,27 +84,27 @@
|
||||
|
||||
**Типи ключів:**
|
||||
|
||||
- **Function Keys:** Ключі функцій можуть бути або за замовчуванням, або визначеними користувачем і призначені для надання доступу виключно до **конкретних кінцевих точок функцій** в рамках Function App, що дозволяє більш детально контролювати доступ до кінцевих точок.
|
||||
- **Host Keys:** Ключі хоста, які також можуть бути за замовчуванням або визначеними користувачем, надають доступ до **всіх кінцевих точок функцій в рамках Function App з рівнем доступу FUNCTION**.
|
||||
- **Master Key:** Ключ майстра (`_master`) слугує адміністративним ключем, який пропонує підвищені права, включаючи доступ до всіх кінцевих точок функцій (включаючи рівень доступу ADMIN). Цей **ключ не може бути відкликаний.**
|
||||
- **System Keys:** Системні ключі **керуються конкретними розширеннями** і потрібні для доступу до кінцевих точок вебхуків, які використовуються внутрішніми компонентами. Прикладами є тригер Event Grid та Durable Functions, які використовують системні ключі для безпечної взаємодії зі своїми відповідними API.
|
||||
- **Ключі функцій:** Ключі функцій можуть бути або за замовчуванням, або визначеними користувачем і призначені для надання доступу виключно до **конкретних кінцевих точок функцій** в рамках Function App, що дозволяє більш детальний доступ до кінцевих точок.
|
||||
- **Ключі хоста:** Ключі хоста, які також можуть бути за замовчуванням або визначеними користувачем, надають доступ до **всіх кінцевих точок функцій в рамках Function App з рівнем доступу FUNCTION**.
|
||||
- **Ключ майстра:** Ключ майстра (`_master`) слугує адміністративним ключем, який пропонує підвищені права, включаючи доступ до всіх кінцевих точок функцій (включаючи рівень доступу ADMIN). Цей **ключ не може бути відкликаний.**
|
||||
- **Системні ключі:** Системні ключі **керуються конкретними розширеннями** і потрібні для доступу до кінцевих точок вебхуків, які використовуються внутрішніми компонентами. Прикладами є тригер Event Grid та Durable Functions, які використовують системні ключі для безпечної взаємодії зі своїми відповідними API.
|
||||
|
||||
> [!TIP]
|
||||
> Приклад доступу до кінцевої точки API функції за допомогою ключа:
|
||||
>
|
||||
> `https://<function_uniq_name>.azurewebsites.net/api/<endpoint_name>?code=<access_key>`
|
||||
|
||||
### Basic Authentication
|
||||
### Базова аутентифікація
|
||||
|
||||
Так само як і в App Services, функції також підтримують базову аутентифікацію для підключення до **SCM** та **FTP** для розгортання коду, використовуючи **ім'я користувача та пароль в URL**, наданому Azure. Більше інформації про це в:
|
||||
Так само, як і в App Services, функції також підтримують базову аутентифікацію для підключення до **SCM** та **FTP** для розгортання коду, використовуючи **ім'я користувача та пароль у URL**, наданому Azure. Більше інформації про це в:
|
||||
|
||||
{{#ref}}
|
||||
az-app-service.md
|
||||
{{#endref}}
|
||||
|
||||
### Github Based Deployments
|
||||
### Розгортання на основі Github
|
||||
|
||||
Коли функція генерується з репозиторію Github, веб-консоль Azure дозволяє **автоматично створити робочий процес Github у конкретному репозиторії**, тому що щоразу, коли цей репозиторій оновлюється, код функції оновлюється. Насправді YAML дії Github для функції на python виглядає так:
|
||||
Коли функція генерується з репозиторію Github, веб-консоль Azure дозволяє **автоматично створити робочий процес Github у конкретному репозиторії**, тому що щоразу, коли цей репозиторій оновлюється, код функції оновлюється. Насправді YAML дії Github для функції Python виглядає так:
|
||||
|
||||
<details>
|
||||
|
||||
@@ -199,7 +199,7 @@ package: ${{ env.AZURE_FUNCTIONAPP_PACKAGE_PATH }}
|
||||
|
||||
### Container Based Deployments
|
||||
|
||||
Не всі плани дозволяють розгортати контейнери, але для тих, що дозволяють, конфігурація міститиме URL контейнера. В API налаштування **`linuxFxVersion`** матиме щось на зразок: `DOCKER|mcr.microsoft.com/...`, тоді як у веб-консолі конфігурація відображатиме **image settings**.
|
||||
Не всі плани дозволяють розгортати контейнери, але для тих, які це дозволяють, конфігурація міститиме URL контейнера. В API налаштування **`linuxFxVersion`** матиме щось на зразок: `DOCKER|mcr.microsoft.com/...`, тоді як у веб-консолі конфігурація відображатиме **image settings**.
|
||||
|
||||
Більше того, **жоден вихідний код не буде зберігатися в обліковому записі зберігання**, пов'язаному з функцією, оскільки це не потрібно.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user