Local File Inclusion Exploit - how to stop
Thanks for this great site - just discovered it - after receiving reports that my component com_biblestudy had been listed as vulnerable to a Local File Inclusion exploit on:
http://docs.joomla.org/Vulnerable_Extensions_List#January_2010_Repo...
The exploit is apparently by using option=com_biblestudy&view=studieslist&controller= and then following that with a bunch of directory parents and then to the passwd file in the etc folder.
I assume the way the exploit is working is that there is a require_once command to a file.
The exploit does something on some servers, but not sure exactly what - the exploit is reported with examples.
Is there a way to stop this?
The code in the controller that may be the problem is:
$abspath = JPATH_SITE;
require_once($abspath.DS.'components/com_biblestudy/class.biblestudydownload.php');
Does anyone have any advice?
http://docs.joomla.org/Vulnerable_Extensions_List#January_2010_Repo...
The exploit is apparently by using option=com_biblestudy&view=studieslist&controller= and then following that with a bunch of directory parents and then to the passwd file in the etc folder.
I assume the way the exploit is working is that there is a require_once command to a file.
The exploit does something on some servers, but not sure exactly what - the exploit is reported with examples.
Is there a way to stop this?
The code in the controller that may be the problem is:
$abspath = JPATH_SITE;
require_once($abspath.DS.'components/com_biblestudy/class.biblestudydownload.php');
Does anyone have any advice?
Views: 327
Replies to This Discussion
-
Permalink Reply by Nathan Bohn on -
So is it the controller option that is being attacked?
well you could just sanitize the controller input. so you could do a compare of your current controllers and if the string doesnt match, be able to kill it. However im not entirely sure how this vulnerability doesnt affect all components? dont they all have the &controller= option? maybe im just missing something. -
-
Permalink Reply by Tom Fuller on -
That's what I thought too.
This is how they vulnerability is portrayed:
http://site/ [Yol] /index.php?option=com_biblestudy&id=1&view=studieslist&controller= [-LFI-]
It's done this way:
http://www.somewebsite.com/index.php?option=com_biblestudy&id=1...
At this link they have some sites that this apparently works on:
http://www.packetstormsecurity.org/1001-exploits/joomlabiblestudy-l...
I've tried to substitute other contollers in the component but don't get any results. Other controllers are studydetails, teacherdisplay, serieslist (this one may also be vulnerable), seriesdetail, and commentlist.
The only two it seems to work on happen to also be the ones using the require_once and a local file.
How could I sanitize the controller input I wonder ... -
-
Permalink Reply by Amy Stephen on
-
Welcome, Tom, thanks for joining in.
It appears Secunia has a report on the Bible Study Extension for remote file inclusion vulnerability.
It appears this statement is missing from the controller.php file. Quick glance at many of the other files shows that safety guard is in place in the other files I looked at.
defined('_JEXEC') or die();
But the error they are noting on Secunia (as follows/and as you noted in your post above) - is not explained by that fix I am suggesting.
Input passed to the "controller" parameter in index.php (if "option" is set to "com_biblestudy" and "view" is set to "studieslist") is not properly verified before being used to include files.
Your require_once statement is fine. The $abspath comes from a Joomla! Constant - and the remainder of the statement is hardcoded.
Here's a good post on Remote File Inclusion Vulnerabilities. The problem would be not sanitizing the input and simply using it, as passed in on the request, from the user.
http://example.com/index.php?page_passed_in_from_url=http://go...
And, without filtering the input, it is simply included, as is:
include $_REQUEST['page_passed_in_from_url'];
Do you ever use an include or require statement using the value from a parameter? If so, that's where I would look.
Hopefully others will pop in too and I'll try to find time to look, as well. -
-
Permalink Reply by Tom Fuller on
-
Thanks Amy and Gergo.
I changed the code in biblestudy.php to getWord. My only problem now is how to test.
This vulnerability only seems to happen on certain servers and I'm not even sure why. But I'll go ahead and release this patch immediately.
Amy - I do have this line in controller.php
defined('_JEXEC') or die();
jimport('joomla.application.component.controller');
You guys are great to help!
Tom -
-
Permalink Reply by Tom Fuller on
-
I've been in contact with one of the sites whose server is vulnerable and he is testing the patch now. So hopefully this will be solved. You guys are lifesavers!
Gergő Erdősi said:Simple do a die() or var_dump() on $controller and try to access the component using different controller values in the URL. If the variable is filtered correctly (allows only the characters [A-Za-z_]), then you fixed the vulnerability. -
-
-
Tom Fuller said:
Amy - I do have this line in controller.php defined('_JEXEC') or die();
I should have said - the administrator/controller.php - sorry about that! This was a great question and now because of Gergo's advice - I have something else to be looking for. Thanks!
jimport('joomla.application.component.controller'); -
-
Permalink Reply by Tom Fuller on
-
I also changed a line further down that read:
$controller->execute( JRequest::getVar('task'));
To:
$controller->execute( JRequest::getWord('task')); -
-
Permalink Reply by Nathan Bohn on
-
had to look it up, but getWord is a joomla lib function:
JRequest::getWord() is a proxy method to JRequest::getVar() which is used to get a variable from the request and sanitize it. The getWord() part means to pass it through what we call the "word" filter. The word filter allows alphanumeric characters plus underscores and dashes I believe.
J! Forum -
-
Permalink Reply by Herman Peeren on -
JRequest::getCmd() is also widely used to get the controller: then you can also have numbers and a point in your input (could be handy if you want to call a controller "number2" e.g.); because slash or percentage-sign may not be used in getCmd(), it is also safe, I'd say. But thanx to this thread I'll personally stick to getWord() i.s.o. getCmd() in the future. Some solutions are more safe than others.
See: http://api.joomla.org/Joomla-Framework/Environment/JRequest.html for the different input-filters.
Here another "nice" article about local file inclusion exploit: http://labs.neohapsis.com/2008/07/21/local-file-inclusion-%E2%80%93...
O, and: wish you all the best with it. Very anoying those attacks. -
-
Permalink Reply by Cedric Walter on -
Good code is important, without review or automated code convention check (phpcheckstyle) it is illusory to hope that unknown code will hold long enough. Not using latest version is even worse, But I stop complaining (also just want to give some kyes for the future). Your first line of defense is the code
The second one, a correctly configured environment, would have turn this attack to no effect:
php.ini open_basedir restrictions would have allow only to open file in /tmp or /srv or /www not everywhere on your filesystem
add
apache mod_security (stateful software firewall for web applications) would have recognized this attack in http payload
I see 20 such hacks per minute on my root server, all unsuccessful :-)
Good luck -
-
Permalink Reply by Tom Fuller on
-
I think you are dead on - and I think why this exploit was not really very successful - most servers were already configured to stop it. On my code, I was copying from tutorials and code others had written but should not have assumed it was "safe" especially as hackers become more sophisticated and focus on open source code to exploit.
Hopefully now at least this component is safer!
Tom -
-
Permalink Reply by C O'Shea on -
The most common attack i see is still the old mos_config. Most of the skids at the moment are using the sql injection with the jos_user. if if was jostick_user, it wouldn't work, or mostly wouldn't.
I hope that you email/tweet your extension users to compel them to upgrade for your sanity and their servers sake. -
© 2012 Created by Amy Stephen.
