Hi Andrea,
Did you get that error for /wp-content/plugins/nginx-compatibility/nginx-compatibility.php or for some other path?
Thank you,
Vladimir
Hi Vladimir,
websecurify tells that there’s a flaw but doesn’t really tells nothing more.
I am about to delve deeper this issue tonight or tomorrow. I am no expert when it comes to security assessment. Today it was a quiet day at the office and I tried few tools to test my server. That’s all.
If you tell me how to test that directly I can try and answer you.
Otherwise you can try websecurify scan your server/wp/plugin and see.
http://www.websecurify.com/
cheers
Ah, I see then. You see, WordPress itself is vulnerable to path disclosure vulnerabilities and then only thing you can do is not to show errors on the screen, e.g. by addinig
display_errors = Off
to your php.ini.
To test if the plugin itself is vulnerable, you should try opening any PHP file in the plugin directory.
For example, if you open example.com/wp-content/plugins/nginx-compatibility/nginx-compatibility.php and it says something like “Fatal error: blah-blah-blah in /path/to/your/wordpress” then nginx-compatibility is vulnerable to this attack.
To prove that WordPress by default is vulnerable: if you open, say, http://www.lifestylemoneymanagement.com.au/wp-settings.php (random site), you will see smth like this:
Warning: require(ABSPATHwp-includes/load.php) [function.require]: failed to open stream: No such file or directory in /home/lifestyl/public_html/wp-settings.php on line 21
The reason for that is that WordPress does not check whether all necessary constants have been defined/required files have been included. Sad but true.
Hi Vladimir,
I see. That is both good and sad news.
Good because I see nothing when I load wp-settings.php or anything in the plugins.
Bad because of this flaw in WP.
Good because I see nothing even if I set display_errors = on
Bad because my nginx try_files it seems not to be working.
In fact I should be redirected to /index.php when calling something like wp-settings.php (if I understood my try_files set up well enough).
Thank You for support and I apologize for saying it was not working.
ps: I guess that other “* disclosures” are to be considered WP’s fault?
In fact I should be redirected to /index.php when calling something like wp-settings.php
If wp-settings.php exists, you won’t be redirected to index.php.
I guess you use smth like:
try_files $uri $uri/ /index.php
In this case nginx first looks for file matching the request URI, if it fails, it tries to find a directory matching the requesr URI and if that fails as well, it will fall back to index.php.
I guess that other “* disclosures” are to be considered WP’s fault?
Path disclosures? Yes and no. Yes, WordPress is affected to this, but a lot of the 3rd party WP themes and plugins are affected as well.
Yes that’s my try_files config , so I didn’t understand it fully.
These are the other disclosures that websecurify (chrome plugin since osx version costs a lot of money) finds:
1st: Banner Disclosure; (who cares…)
2nd: Path Disclosure; (we are talking about it)
3rd: User Disclosure; (this scares me)
4th: not really a disclosure and last “issue” is: Cross-site Request Forgery
I am not really happy about them, but on the good side: it found “only” 4 issues. (1 issue is already one too many issues for my taste, but hey… considering I am not expert… ;))
Anyway I am going off-topic.
Thanks for your kind support.
ps: beside that I would like to test malicious file upload/download/execution but I don’t know how to do that for now. Trying the suits for starter and understanding of how it works. I’ll see what I can learn and get safer.
OMFG.
Now that I understood this…… I can say that it was a fake and that I doubt the goodness of websecurify chrome plugin. Here the two disclosure errors:
Path Disclosure
Various system paths were disclosed within the application client source code or other files. This information could be used by attackers to make an educated guess about the application environment and any inherited weaknesses that may come with it.
solution: It is recommended to re-examine the system path disclosures and remove their reference from the application’s source code.
path: /home/kemu …
request: GET http://cga.cx/tag/code-2/ HTTP/1.1
=========
User Disclosure
Various usernames were disclosed within the application client source code or other files. This information could be used by attackers to attack the login mechanism on the application and supporting infrastructure.
solution: It is recommended to re-examine the username disclosures and remove their reference from the application’s source code.
user: home/kemu …
request: GET http://cga.cx/tag/code-2/ HTTP/1.1
=======
Now. I understand that those paths are really something standard on Linux… but these two are clearly two frikking false positives.
Navigate to that URL: http://cga.cx/tag/code-2/ , select this article http://cga.cx/2011/07/11/kvmms/ and see the two “disclosures” in the “kemu” links.
d’oh!!!
