mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/binary-exploitation/rop-return-oriented-programing/srop
This commit is contained in:
Translator
parent
05b47bd16a
commit
23084b39ff
@ -74,7 +74,7 @@ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space # Disable ASLR
|
||||
```
|
||||
## Exploit
|
||||
|
||||
Експлойт використовує bof, щоб повернутися до виклику **`sigreturn`** та підготувати стек для виклику **`execve`** з вказівником на `/bin/sh`.
|
||||
Експлойт використовує bof, щоб повернутися до виклику **`sigreturn`** і підготувати стек для виклику **`execve`** з вказівником на `/bin/sh`.
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -136,7 +136,7 @@ return 0;
|
||||
|
||||
<figure><img src="../../../images/image (17) (1).png" alt="" width="563"><figcaption></figcaption></figure>
|
||||
|
||||
Отже, якщо буде витік, можна **використати цю адресу для доступу до `sigreturn`**, якщо бінарний файл не завантажує його:
|
||||
Отже, якщо буде витік, можна **використати цю адресу для доступу до `sigreturn`**, якщо бінар не завантажує його:
|
||||
```python
|
||||
from pwn import *
|
||||
|
||||
@ -181,7 +181,7 @@ p.interactive()
|
||||
|
||||
## Автоматичне знаходження гаджетів `sigreturn` (2023-2025)
|
||||
|
||||
У сучасних дистрибутивах `sigreturn` тромпліна все ще експортується сторінкою **vDSO**, але точний зсув може варіюватися в залежності від версій ядра та параметрів збірки, таких як BTI (`+branch-protection`) або PAC. Автоматизація його виявлення запобігає жорсткому кодуванню зсувів:
|
||||
У сучасних дистрибутивах `sigreturn` тромплін все ще експортується сторінкою **vDSO**, але точний зсув може варіюватися в залежності від версій ядра та параметрів збірки, таких як BTI (`+branch-protection`) або PAC. Автоматизація його виявлення запобігає жорсткому кодуванню зсувів:
|
||||
```bash
|
||||
# With ROPgadget ≥ 7.4
|
||||
python3 -m ROPGadget --binary /proc/$(pgrep srop)/mem --only "svc #0" 2>/dev/null | grep -i sigreturn
|
||||
@ -191,7 +191,7 @@ rp++ -f ./binary --unique -r | grep "mov\s\+x8, #0x8b" # 0x8b = __NR_rt_sigret
|
||||
```
|
||||
Обидва інструменти розуміють **AArch64** кодування і перерахують кандидатні `mov x8, 0x8b ; svc #0` послідовності, які можна використовувати як *SROP gadget*.
|
||||
|
||||
> Примітка: Коли бінарні файли компілюються з **BTI**, перша інструкція кожної дійсної цілі непрямого переходу є `bti c`. `sigreturn` тромпліни, розміщені компілятором, вже містять правильну BTI приземну платформу, тому гаджет залишається придатним для використання з неправа кодом.
|
||||
> Примітка: Коли бінарні файли компілюються з **BTI**, перша інструкція кожної дійсної цілі непрямого переходу - це `bti c`. `sigreturn` тромпліни, розміщені компілятором, вже містять правильну BTI приземну платформу, тому гаджет залишається придатним для використання з неправа кодом.
|
||||
|
||||
## Зв'язування SROP з ROP (поворот через `mprotect`)
|
||||
|
||||
@ -213,17 +213,17 @@ Linux 5.16 ввів більш сувору валідацію сигналів
|
||||
|
||||
* `uc_flags` повинен містити `UC_FP_XSTATE`, коли присутній `extra_context`.
|
||||
* Зарезервоване слово в `struct rt_sigframe` повинно бути нульовим.
|
||||
* Кожен вказівник у запису *extra_context* вирівняний і вказує всередину адресного простору користувача.
|
||||
* Кожен вказівник у записі *extra_context* вирівняний і вказує всередину адресного простору користувача.
|
||||
|
||||
`pwntools>=4.10` автоматично створює відповідні кадри, але якщо ви створюєте їх вручну, переконайтеся, що ви ініціалізували *reserved* нулями і пропустіть запис SVE, якщо ви дійсно не потребуєте його — в іншому випадку `rt_sigreturn` поверне `SIGSEGV` замість повернення.
|
||||
`pwntools>=4.10` автоматично створює відповідні кадри, але якщо ви створюєте їх вручну, переконайтеся, що ви ініціалізували *reserved* нулями і пропустіть запис SVE, якщо ви дійсно не потребуєте його — в іншому випадку `rt_sigreturn` поверне `SIGSEGV` замість того, щоб повернутися.
|
||||
|
||||
Починаючи з основного Android 14 та Fedora 38, користувацький простір компілюється з увімкненими за замовчуванням **PAC** (*Pointer Authentication*) та **BTI** (`-mbranch-protection=standard`). *SROP* сам по собі не підлягає впливу, оскільки ядро безпосередньо перезаписує `PC` з підготовленого кадру, обходячи автентифікований LR, збережений на стеку; однак будь-який **наступний ROP-ланцюг**, який виконує непрямі переходи, повинен переходити до інструкцій з увімкненим BTI або PAC-адресам. Майте це на увазі при виборі гаджетів.
|
||||
|
||||
Shadow-Call-Stacks, введені в ARMv8.9 (і вже увімкнені на ChromeOS 1.27+), є мірою пом'якшення на рівні компілятора і *не* заважають SROP, оскільки жодні інструкції повернення не виконуються — потік управління передається ядром.
|
||||
Shadow-Call-Stacks, введені в ARMv8.9 (і вже увімкнені на ChromeOS 1.27+), є мірою захисту на рівні компілятора і *не* заважають SROP, оскільки жодні інструкції повернення не виконуються — потік управління передається ядром.
|
||||
|
||||
## Посилання
|
||||
|
||||
* [Документація з обробки сигналів Linux arm64](https://docs.kernel.org/arch/arm64/signal.html)
|
||||
* [LWN – "AArch64 branch protection comes to GCC and glibc" (2023)](https://lwn.net/Articles/915041/)
|
||||
* [LWN – "Захист гілок AArch64 приходить до GCC та glibc" (2023)](https://lwn.net/Articles/915041/)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -6,11 +6,11 @@
|
||||
|
||||
Є 3 способи вказати вміст сторінки в iframe:
|
||||
|
||||
- Через `src`, вказуючи URL (URL може бути крос-доменним або того ж домену)
|
||||
- Через `src`, вказуючи вміст за допомогою протоколу `data:`
|
||||
- Через `srcdoc`, вказуючи вміст
|
||||
- Через `src`, що вказує на URL (URL може бути крос-доменним або того ж домену)
|
||||
- Через `src`, що вказує на вміст, використовуючи протокол `data:`
|
||||
- Через `srcdoc`, що вказує на вміст
|
||||
|
||||
**Доступ до змінних батьківського та дочірнього контексту**
|
||||
**Доступ до змінних батьківського та дочірнього контекстів**
|
||||
```html
|
||||
<html>
|
||||
<script>
|
||||
@ -105,9 +105,9 @@ app.run()
|
||||
```
|
||||
#### Нові (2023-2025) техніки обходу CSP з використанням iframe
|
||||
|
||||
Дослідницька спільнота продовжує знаходити креативні способи зловживання iframe для подолання обмежувальних політик. Нижче ви можете знайти найбільш помітні техніки, опубліковані за останні кілька років:
|
||||
Дослідницька спільнота продовжує знаходити креативні способи зловживання iframe для обходу обмежувальних політик. Нижче ви можете знайти найбільш помітні техніки, опубліковані за останні кілька років:
|
||||
|
||||
* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Коли додаток відображає HTML, але сильний CSP блокує виконання скриптів, ви все ще можете витікати чутливі токени, інжектуючи *dangling* `<iframe name>` атрибут. Як тільки частковий розмітка буде проаналізована, скрипт зловмисника, що працює в іншому походженні, перенаправляє фрейм на `about:blank` і читає `window.name`, який тепер містить все до наступного символу лапок (наприклад, CSRF токен). Оскільки жоден JavaScript не виконується в контексті жертви, атака зазвичай обходить `script-src 'none'`. Мінімальний PoC:
|
||||
* **Dangling-markup / named-iframe data-exfiltration (PortSwigger 2023)** – Коли додаток відображає HTML, але сильний CSP блокує виконання скриптів, ви все ще можете витікати чутливі токени, інжектуючи *dangling* `<iframe name>` атрибут. Як тільки частковий розмітка буде проаналізована, скрипт зловмисника, що працює в окремому походженні, перенаправляє фрейм на `about:blank` і читає `window.name`, який тепер містить все до наступного символу лапок (наприклад, CSRF токен). Оскільки жоден JavaScript не виконується в контексті жертви, атака зазвичай обходить `script-src 'none'`. Мінімальний PoC:
|
||||
|
||||
```html
|
||||
<!-- Точка інжекції безпосередньо перед чутливим <script> -->
|
||||
@ -155,32 +155,32 @@ src='data:text/html,<script defer="true" src="data:text/javascript,document.body
|
||||
|
||||
Вміст в iframe може підлягати додатковим обмеженням за допомогою атрибута `sandbox`. За замовчуванням цей атрибут не застосовується, що означає, що обмеження не діють.
|
||||
|
||||
При використанні атрибут `sandbox` накладає кілька обмежень:
|
||||
Коли використовується, атрибут `sandbox` накладає кілька обмежень:
|
||||
|
||||
- Вміст розглядається так, ніби він походить з унікального джерела.
|
||||
- Будь-яка спроба надсилання форм блокується.
|
||||
- Виконання скриптів заборонено.
|
||||
- Доступ до певних API відключено.
|
||||
- Він запобігає взаємодії посилань з іншими контекстами перегляду.
|
||||
- Це запобігає взаємодії посилань з іншими контекстами перегляду.
|
||||
- Використання плагінів через `<embed>`, `<object>`, `<applet>` або подібні теги заборонено.
|
||||
- Навігація верхнього рівня контексту перегляду вмістом сама по собі заборонена.
|
||||
- Автоматично активовані функції, такі як відтворення відео або автоматичне фокусування елементів форм, блокуються.
|
||||
- Функції, які запускаються автоматично, такі як відтворення відео або автоматичне фокусування елементів форм, блокуються.
|
||||
|
||||
Tip: Сучасні браузери підтримують детальні прапорці, такі як `allow-scripts`, `allow-same-origin`, `allow-top-navigation-by-user-activation`, `allow-downloads-without-user-activation` тощо. Поєднуйте їх, щоб надати лише мінімальні можливості, необхідні вбудованому додатку.
|
||||
|
||||
Значення атрибута можна залишити порожнім (`sandbox=""`), щоб застосувати всі вищезгадані обмеження. Альтернативно, його можна встановити на список специфічних значень, розділених пробілами, які звільняють iframe від певних обмежень.
|
||||
Значення атрибута можна залишити порожнім (`sandbox=""`), щоб застосувати всі вищезазначені обмеження. Альтернативно, його можна встановити на список специфічних значень, розділених пробілами, які звільняють iframe від певних обмежень.
|
||||
```html
|
||||
<!-- Isolated but can run JS (cannot reach parent because same-origin is NOT allowed) -->
|
||||
<iframe sandbox="allow-scripts" src="demo_iframe_sandbox.htm"></iframe>
|
||||
```
|
||||
### Credentialless iframes
|
||||
|
||||
Як пояснено в [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), прапорець `credentialless` в iframe використовується для завантаження сторінки всередині iframe без відправки облікових даних у запиті, зберігаючи при цьому політику одного походження (SOP) завантаженої сторінки в iframe.
|
||||
Як пояснюється в [this article](https://blog.slonser.info/posts/make-self-xss-great-again/), прапорець `credentialless` в iframe використовується для завантаження сторінки всередині iframe без відправки облікових даних у запиті, зберігаючи при цьому політику одного походження (SOP) завантаженої сторінки в iframe.
|
||||
|
||||
Оскільки **Chrome 110 (лютий 2023) ця функція увімкнена за замовчуванням** і специфікація стандартизована в різних браузерах під назвою *anonymous iframe*. MDN описує це як: “механізм для завантаження iframe третьої сторони в абсолютно нову, епhemeral storage partition, щоб жодні куки, localStorage або IndexedDB не ділилися з реальним походженням”. Наслідки для атакуючих і захисників:
|
||||
Оскільки **Chrome 110 (лютий 2023) ця функція увімкнена за замовчуванням** і специфікація стандартизована в браузерах під назвою *анонімний iframe*. MDN описує це як: “механізм для завантаження iframe третьої сторони в абсолютно нову, епhemeral storage partition, щоб жодні куки, localStorage або IndexedDB не ділилися з реальним походженням”. Наслідки для атакуючих і захисників:
|
||||
|
||||
* Скрипти в різних credentialless iframes **все ще ділять одне й те саме верхнє походження** і можуть вільно взаємодіяти через DOM, що робить атаки multi-iframe self-XSS можливими (див. PoC нижче).
|
||||
* Оскільки мережа **позбавлена облікових даних**, будь-який запит всередині iframe фактично поводиться як неавтентифікована сесія – захищені CSRF кінцеві точки зазвичай не проходять, але публічні сторінки, які можна витікати через DOM, все ще в межах досяжності.
|
||||
* Скрипти в різних credentialless iframes **все ще ділять одне й те саме верхнє походження** і можуть вільно взаємодіяти через DOM, що робить можливими атаки multi-iframe self-XSS (див. PoC нижче).
|
||||
* Оскільки мережа є **без облікових даних**, будь-який запит всередині iframe фактично поводиться як неавтентифікована сесія – захищені CSRF кінцеві точки зазвичай не проходять, але публічні сторінки, які можна витікати через DOM, все ще в межах досяжності.
|
||||
* Вікна, що з'являються з credentialless iframe, отримують неявний `rel="noopener"`, що порушує деякі потоки OAuth.
|
||||
```javascript
|
||||
// PoC: two same-origin credentialless iframes stealing cookies set by a third
|
||||
@ -209,7 +209,7 @@ document.forms[0].submit();
|
||||
|
||||
- Інший iframe, в якому насправді користувач увійшов в систему (без прапора `credentialless`).
|
||||
|
||||
Тоді, з XSS, можливо отримати доступ до іншого iframe, оскільки вони мають одну SOP, і вкрасти кукі, наприклад, виконавши:
|
||||
Тоді з XSS можливо отримати доступ до іншого iframe, оскільки вони мають одну SOP, і вкрасти кукі, наприклад, виконавши:
|
||||
```javascript
|
||||
alert(window.top[1].document.cookie);
|
||||
```
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user