ResponsiveFilemanager icon indicating copy to clipboard operation
ResponsiveFilemanager copied to clipboard

server side request forgery vulnerability in url uploader bypass CVE-2018-14728 by adding /favicon.ico to end of php file.

Open hackoclipse opened this issue 5 years ago • 6 comments

Good afternoon ResponsiveFilemanager,

When i was doing a security test for a client of mine i noticed in your newest version of ResponsiveFilemanager 9.13.4 ( in 9.14.0 the url upload is completly broken but it also exist there ) internal server side request forgery by adding to any php "/image.ico".

to reproduce this i reccomand to install ResponsiveFilemanager 9.13.4 and not ResponsiveFilemanager 9.14.0 because the url file uploader is completly broken and doesn't work at all even with legit jpeg's, but this version is also vulnerble.

you need to have url_upload enabled and run the code on a apache server with default configurations. now send as url

http://0.xip.io/server-status/favicon.ico

when you send that go back to the file manager and you will see a ico. download that file and rename favicon.ico to favicon.html. if you now open that you will see the apache status page. as you can see this is a clear indication that CVE-2018-14728 is bypassable.

how does this work: there are a few problems here. first you only use a regex to verify if it is a allowed url. and in php files ( and sometimes html files ) it is allowed to extend the url. this means if i would go to index.php/favicon.ico than the apache server would return index.php and not favicon.ico, but it would extend the url. secondly i use dns pinning to bypass your miner filter to check if you send localhost because if you do a nslookup on "0.xip.io" you will get:

bl4ckh4ck5@bl4ckh4ck5-laptop:~/$ nslookup 0.xip.io Server: 10.5.0.1 Address: 10.5.0.1#53

Non-authoritative answer: Name: 0.xip.io Address: 0.0.0.0

and 0.0.0.0 is localhost, but this method could also be used to access other ip's in the network.

a while back i created a potential patch against SSRF what might help against this problem: https://github.com/hackoclipse/ssrf-patch but i reccomand to make the design client side that the webbrowser downloads the image and than you use a xmlhttprequest to request the normal file upload, because that function isn't vulnerble. i reccomand to fix both problems that url upload works again in 9.14.0 and that you fix this internal server side request forgery. A CVE is already been requested.

Dear ragards,

bl4ckh4ck5 https://hackoclipse.com

hackoclipse avatar Mar 05 '20 05:03 hackoclipse

in version 9.14.0 it also bypasses the preg_match but a little lower it brakes because of a programming mistake: https://github.com/trippo/ResponsiveFilemanager/blob/master/filemanager/upload.php#L73 so when that bug gets fixxed it's very likely it becomes vulnerble again.

hackoclipse avatar Mar 05 '20 05:03 hackoclipse

later noticed 127.0.0.1 and 0.0.0.0 also worked but at the company i found this vulnerability i used 0.xip.io to bypass there firewall.

hackoclipse avatar Mar 05 '20 06:03 hackoclipse

hmm after looking closer i was able to find the commit what made the bug: https://github.com/trippo/ResponsiveFilemanager/commit/8478bd4c9ab8e2f85781d00e1656ce4ec861067c after this commit was done a bug was created that url upload doesn't work anymore in 9.14.0. ( even latest commit )

hackoclipse avatar Mar 05 '20 09:03 hackoclipse

cve assinged: CVE-2020-10212

hackoclipse avatar Mar 07 '20 11:03 hackoclipse

after more testing i noticed this method also work with extension blacklist enabled in the config. it isn't specificly ico files that work any file what isn't blacklist'ed would work.

hackoclipse avatar Mar 07 '20 16:03 hackoclipse

any commit fixing the issue above?

tamir-ben avatar Sep 07 '20 14:09 tamir-ben