Apache
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Перевірте, які розширення виконує сервер Apache. Щоб їх знайти, ви можете виконати:
Також деякі місця, де ви можете знайти цю конфігурацію, це:
Цей тип атак був представлений і задокументований компанією Orange у цьому блозі, і нижче наведено резюме. Атака "confusion" в основному зловживає тим, як десятки модулів, які працюють разом, створюючи Apache, не працюють ідеально синхронізовано, і змушуючи деякі з них модифікувати деякі неочікувані дані може викликати вразливість у наступному модулі.
mod_rewrite обрізає вміст r->filename після символу ? (modules/mappers/mod_rewrite.c#L4141). Це не зовсім неправильно, оскільки більшість модулів буде розглядати r->filename як URL. Але в інших випадках це буде розглядатися як шлях до файлу, що може викликати проблему.
Path Truncation
Можливо зловживати mod_rewrite, як у наступному прикладі правила, щоб отримати доступ до інших файлів у файловій системі, видаляючи останню частину очікуваного шляху, просто додавши ?:
Помилкове призначення RewriteFlag
У наступному правилі переписування, поки URL закінчується на .php, він буде оброблятися та виконуватися як php. Тому можливо надіслати URL, який закінчується на .php після символу ?, завантажуючи при цьому в шлях файл іншого типу (наприклад, зображення) з шкідливим php-кодом всередині:
Можливо отримати доступ до файлів, до яких користувач не повинен мати доступ, навіть якщо доступ має бути заборонений з такими конфігураціями:
Це пов'язано з тим, що за замовчуванням PHP-FPM отримуватиме URL-адреси, що закінчуються на .php, такі як http://server/admin.php%3Fooo.php, і оскільки PHP-FPM видалить усе після символу ?, попередня URL-адреса дозволить завантажити /admin.php, навіть якщо попереднє правило забороняло це.
Фунт факт про Apache полягає в тому, що попереднє переписування спробує отримати доступ до файлу як з documentRoot, так і з кореня. Отже, запит до https://server/abouth.html перевірить наявність файлу в /var/www/html/about.html та /about.html у файловій системі. Це, по суті, може бути зловжито для доступу до файлів у файловій системі.
Розкрити вихідний код CGI
Просто додавання %3F в кінці достатньо, щоб витоку вихідного коду модуля cgi:
Розкриття вихідного коду PHP
Якщо сервер має різні домени, один з яких є статичним доменом, це можна використати для обходу файлової системи та витоку php коду:
Основна проблема з попередньою атакою полягає в тому, що за замовчуванням більшість доступу до файлової системи буде заборонено, як у шаблоні конфігурації Apache HTTP Server:
Однак, операційні системи Debian/Ubuntu за замовчуванням дозволяють /usr/share:
Тому, було б можливим зловживати файлами, розташованими всередині /usr/share в цих дистрибутивах.
Локальний гаджет для розкриття інформації
Apache HTTP Server з websocketd може відкрити скрипт dump-env.php за адресою /usr/share/doc/websocketd/examples/php/, що може призвести до витоку чутливих змінних середовища.
Сервери з Nginx або Jetty можуть розкрити чутливу інформацію веб-додатків (наприклад, web.xml) через свої стандартні веб-корені, розташовані під /usr/share:
/usr/share/nginx/html/
/usr/share/jetty9/etc/
/usr/share/jetty9/webapps/
Локальний гаджет для XSS
На Ubuntu Desktop з встановленим LibreOffice, експлуатація функції перемикання мови довідкових файлів може призвести до Cross-Site Scripting (XSS). Маніпулювання URL за адресою /usr/share/libreoffice/help/help.html може перенаправити на шкідливі сторінки або старі версії через небезпечний RewriteRule.
Локальний гаджет для LFI
Якщо встановлені PHP або певні фронтенд-пакети, такі як JpGraph або jQuery-jFeed, їх файли можуть бути використані для читання чутливих файлів, таких як /etc/passwd:
/usr/share/doc/libphp-jpgraph-examples/examples/show-source.php
/usr/share/javascript/jquery-jfeed/proxy.php
/usr/share/moodle/mod/assignment/type/wims/getcsv.php
Локальний гаджет для SSRF
Використовуючи MagpieRSS's magpie_debug.php за адресою /usr/share/php/magpierss/scripts/magpie_debug.php, можна легко створити вразливість SSRF, що надає доступ до подальших експлойтів.
Локальний гаджет для RCE
Можливості для Remote Code Execution (RCE) величезні, з вразливими установками, такими як застарілий PHPUnit або phpLiteAdmin. Їх можна експлуатувати для виконання довільного коду, демонструючи широкий потенціал маніпуляцій з локальними гаджетами.
Також можливо вийти з дозволених папок, слідуючи символічним посиланням, створеним встановленим програмним забезпеченням у цих папках, наприклад:
Cacti Log: /usr/share/cacti/site/ -> /var/log/cacti/
Solr Data: /usr/share/solr/data/ -> /var/lib/solr/data
Solr Config: /usr/share/solr/conf/ -> /etc/solr/conf/
MediaWiki Config: /usr/share/mediawiki/config/ -> /var/lib/mediawiki/config/
SimpleSAMLphp Config: /usr/share/simplesamlphp/config/ -> /etc/simplesamlphp/
Більше того, зловживаючи символічними посиланнями, було можливо отримати RCE в Redmine.
Цей напад експлуатує перетин функціональності між директивами AddHandler та AddType, які обидві можуть бути використані для увімкнення обробки PHP. Спочатку ці директиви впливали на різні поля (r->handler та r->content_type відповідно) у внутрішній структурі сервера. Однак, через застарілий код, Apache обробляє ці директиви взаємозамінно за певних умов, перетворюючи r->content_type в r->handler, якщо перше встановлено, а друге - ні.
Більше того, в Apache HTTP Server (server/config.c#L420), якщо r->handler порожній перед виконанням ap_run_handler(), сервер використовує r->content_type як обробник, ефективно роблячи AddType та AddHandler ідентичними за ефектом.
У цьому виступі була представлена вразливість, де неправильний Content-Length, надісланий клієнтом, може призвести до того, що Apache помилково поверне PHP вихідний код. Це сталося через проблему обробки помилок з ModSecurity та Apache Portable Runtime (APR), де подвоєна відповідь призводить до перезапису r->content_type на text/html.
Оскільки ModSecurity не обробляє належним чином значення повернення, він поверне PHP код і не інтерпретує його.
TODO: Orange ще не розкрив цю вразливість
Якщо зловмисник може контролювати заголовок Content-Type у відповіді сервера, він зможе викликати довільні модульні обробники. Однак, на момент, коли зловмисник контролює це, більшість процесу запиту буде завершено. Проте, можливо перезапустити процес запиту, зловживаючи заголовком Location, оскільки якщо returned Status дорівнює 200 і заголовок Location починається з /, відповідь обробляється як серверне перенаправлення і повинна бути оброблена.
Згідно з RFC 3875 (специфікація про CGI) у Розділі 6.2.2 визначається поведінка локальної відповіді перенаправлення:
CGI-скрипт може повернути URI шлях і рядок запиту (‘local-pathquery’) для локального ресурсу в заголовку Location. Це вказує серверу, що він повинен повторно обробити запит, використовуючи вказаний шлях.
Отже, для виконання цього нападу потрібна одна з наступних вразливостей:
CRLF Injection у заголовках відповіді CGI
SSRF з повним контролем заголовків відповіді
Наприклад, /server-status повинен бути доступний лише локально:
Можливо отримати доступ, встановивши Content-Type на server-status і заголовок Location, що починається з /
Перенаправлення до mod_proxy для доступу до будь-якого протоколу за будь-якою URL:
Однак заголовок X-Forwarded-For додається, що заважає доступу до кінцевих точок метаданих хмари.
Доступ до локального сокета Unix Domain PHP-FPM для виконання PHP бекдору, розташованого в /tmp/:
Офіційний PHP Docker образ включає PEAR (Pearcmd.php), інструмент управління пакетами PHP з командного рядка, який можна зловживати для отримання RCE:
Перевірте Docker PHP LFI Summary, написаний Phith0n для деталей цієї техніки.
Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
