filebrowser.php exploit (Security Issue)

[yurifanboy]

http://packetstormsecurity.org/files/111...-shell.txt
+> Exploit :
http://[target]/[path]/admin/filebrowser.php
Anybody see this?

[yojoe]

Nops, I'm being redirected to login page when I try to launch directly .php files in /admin.
Not all files contain directive

Code:

if(!defined('IN_GS')){ die('you cannot load this page directly.'); }

but isn't it doing its job ?

[n00dles101]

You need to be logged in to the backend admin for this 'exploit' to work.

[marrco]

verified on NGINX with Debian Squeeze and GS is safe too. I guess n00dles101 is right, you have to be logged in to use this "exploit"

[Draxeiro]

You need to be logged in to the backend admin for this 'exploit' to work.

Meaning the site owner has to be logged in to the admin for the culprit to be able to make use of the 'exploit' without him noticing?

Would mean mr. wannabe-hacker has to have a great sense of timing but at the same time this hole would need to be plugged anyhow.

Or do you mean the culprit has to be logged in to the admin himself?

[Zegnåt]

Or do you mean the culprit has to be logged in to the admin himself?

That’s what Mike meant. The culprit will need to have access to your admin panel by being logged in. This is like saying WordPress has an enormous leak because someone who is logged in will be able to upload files…

This vulnerability report is lacking. We don’t even know what server software he is using. By default, on Apache with .htaccess files (for which GetSimple is build), the backup folder will be locked, and the XML files are inaccessible as well.

The way I see it he tested the first ‘exploit’ by being logged in and the second on a server that does not support basic .htaccess security.

Anyone can find vulnerabilities when they are not testing on a platform that the software was made to work on.