Guest Posted October 11, 2004 Share Posted October 11, 2004 -------------------------------------------------------- Full path disclosure and sql injection on CubeCart 2.0.1 -------------------------------------------------------- [1]Introduction [2]The Problem [3]The Solution [4]Timeline [5]Feddback ############################################################## [1]Introduction "CubeCart is an eCommerce script written with PHP & MySQL. With CubeCart you can setup a powerful online store as long as you have hosting supporting PHP and one MySQL database." This info was taken from http://www.cubecart.com CubeCart, from Brooky (http://www.brooky.com), is a software formerly known as eStore. [2]The Problem A remote user can cause an error in index.php using the parameter 'cat_id' which is not properly validated, displaying the software's full installation path. It can also be used to inject sql commands. Examples follow: (a) http://example.com/store/index.php?cat_id=' causes an error like this: "Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/example/public_html/store/link_navi.php on line 35 Warning: mysql_num_rows(): supplied argument is not a valid MySQL result resource in /home/example/public_html/store/index.php on line 170 Warning: mysql_fetch_array(): supplied argument is not a valid MySQL result resource in /home/example/public_html/store/index.php on line 172" (http://example.com/store/index.php?cat_id=1 or 1=1-- displays all categories in the database [3]The Solution None at this time. Vendor contacted and fix will be avaliable soon. [4]Timeline (2/10/2004) Vulnerability discovered (2/10/2004) Vendor notified (3/10/2004) Vendor response [5]Feedback Comments and stuff to cybercide megamail pt ------------------------------------------------------------ Does somebody have a fix already? Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2004 Share Posted October 11, 2004 Ok... I can agree that it does exactly as you stated. What I don't understand is why this is a big deal. If the server is set up correctly, no one has access to anything above public_html anyway. As for, sql injection, the examples you have are not injecting anything, only creating an error. Anything that is being written to the database does get checked. Is it bulletproof? Probably not, but those examples definitely don't hurt the database. What you have described is standard mysql behaviour and can be witnessed on many thousands of sites across the web. On the scale of things, this concerns me about as much as a catastrophic server crash. As Brooky pointed out in another post, there is no credit card info stored. The most anyone could hope to get is some phone numbers and addresses. The information garnered from these types of errors are not really help for that anyway. The bottom line is if someone really wants to crash/hack your server, no matter what safegaurds you try to put in place things can happen. At least once a day someone tries to cause a buffer overflow on my server. There are also a steady flow of jerks that are trying to exploit Microsoft vulnerabilities. It is unfortunately the world we live in. From reading your posts, I don't know whether you are really concerned about this thing or just being an alarmist. I am not an "expert". I am also not uneducated about these things. I personally will not be making any changes in my scripts to avoid the errors you describe. It can be done, but IMO is not worth the time and effort. If this thing really bugs you, take a deep breath and realize not everything in this world can be made 100% safe. Then, look through the script. Anyplace you see mysql_fetch_array or mysql_num_rows put a @ in front of it. Something like this: $totalrows = mysql_num_rows($result_count); $totalrows = @mysql_num_rows($result_count); The error is now suppressed. It may still occur, but does not display. I would definitely not recommend doing this on a site that you have to plans to alter in any way in the future. Those displayed errors are used for debugging and to let you know when something is not right in the script. There are other more complicated ways to do this. I offer the above simply as the most convenient solution. Like I said earlier, I won't be doing it to my scripts. I'll just take my chances. Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2004 Share Posted October 11, 2004 May be i just an alarmist. But i think everyone, who is using the CubeCart, has spent a lot of time (and money too) for setting up his e-shop and don't want to lose the results of work. How do You think, how clients will react if they get to know once that the store was hakced by somebody 'clever'? Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2004 Share Posted October 11, 2004 I agree everyone has time and energy involved in the their stores. My point is this is not a real problem. The data is not being corrupted. There is no loss of data. The database itself is not compromised. Like I said earlier if this thing bothers you, add @ in front of the statements on your affected lines. /home/example/public_html/store/link_navi.php on line 35 /home/example/public_html/store/index.php on line 170 /home/example/public_html/store/index.php on line 172 I went against my earlier post and did this just to see how big of a deal it would be to catch all the errors. Turns out only those 3 instances display the error. So, I did in fact make the changes. Now, the error does not get displayed. This is not a Cubecart problem, it is a mysql problem. Beyond adding @, there is nothing that can be done. The only possible solution would be to check in the database to see if the cat_id being passed exists before checking the database to see if it exists. Yes, I typed that right. The solution is not a solution, there is no right way, it cannot be not done. It just is, the best that can be done is not to show the error. How do I think the clients will react? That is irrelevant to this discussion. The phenomena detailed in your original post cannot cause to the data to be corrupted. In a larger sense they may feel violated, disappointed perhaps. But again, the most the client has given away is a name, telphone number, and address. Unless the majority of clients are in a witness protection program, that is no more than you can find using any of the online directories. By far the bigger problem would be the loss of data on the server. I stress again, this does not cause the data to be lost, corrupted, or compromised. There may be ways to do it, but this is not one of them. Everyone is entitled to their own opinion. I would hate for anyone to give up on such a good piece of software because of this trivial thing. Especially since it is fixed so easily. I invite anyone to chime in here with your voice on this. Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2004 Share Posted October 11, 2004 what about something like if (!is_int($cat_id)) unset($cat_id); before include("header.inc.php"); in index.php as a fix? unable to test at moment sorry, if someone would care to test and they could kindly post back here. (if is_int doesn't do it, maybe is_numeric?) I don't view as a big security risk myself, but rather than argue the toss, why not just fix it? B) Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2004 Share Posted October 11, 2004 I agree with grcdude2 that this isn't a big problem. No information is compromised as a result of this error. I think more than anything this thread just stands to alarm those new to cubecart. Suppressing this error will not make your site anymore secure than it is now. Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2004 Share Posted October 11, 2004 Just tested and if (!is_numeric($cat_id)) Â Â unset($cat_id); is the correct one. Suppressing this error will not make your site anymore secure than it is now. just to clarify to other peeps who want their cart water-tight this is not supressing the error, it is preventing it. actually the revealed server path is a slight security compromise in my opinion. Lets give people have the option of fixing it or not. The other thing is if the community is seen to ignore this 'error' and dismiss it, that could just as easily put newbies off the cart. nuff said Quote Link to comment Share on other sites More sharing options...
Guest Posted October 11, 2004 Share Posted October 11, 2004 Sculptex, I am humbled. Nice bit of code there. It handles the problem very nicely. I still have a lot to learn it seems. Quote Link to comment Share on other sites More sharing options...
Guest Posted October 16, 2004 Share Posted October 16, 2004 Thanx for fix! Well done. Applyed in my store B) Quote Link to comment Share on other sites More sharing options...
Guest Posted October 25, 2004 Share Posted October 25, 2004 Sculptex are you saying to replace includes header or just add if (!is_int($cat_id)) unset($cat_id); Before that line? I would be interested in the actual solution instructions, verbatim. Thanks Quote Link to comment Share on other sites More sharing options...
Guest Posted October 25, 2004 Share Posted October 25, 2004 Sculptex are you saying to replace includes header or just add if (!is_int($cat_id)) unset($cat_id); Before that line? I would be interested in the actual solution instructions, verbatim. Thanks Quote Link to comment Share on other sites More sharing options...
Guest Posted October 25, 2004 Share Posted October 25, 2004 insert (additional lines) if (!is_numeric($cat_id)) unset($cat_id); before (but not replacing) include("header.inc.php"); in index.php Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.