How script kiddies can find your vulnerable extensions
Recently a client's Joomla website got cracked, and guess what? Attackers breached through a 3rd party extension (of course not installed or suggested by me). After getting a super admin's credentials via SQL injection, they took the liberty to try the credentials on another website of the client and bingo, got 2 websites under their control and played fantastic background music on a brand new one-page template with vital information about improving my sex life. The client however preferred the old templates and content, so I reconstructed the old sites. Seems like I have to stick to my mum and dad's version about procreation.
The interesting part is how they found the website. I stumbled upon the top search keywords in Google Webmaster Tools and found out that lots of queries were like "option=com_...." (extension name blanked out).
One simply cannot know about all vulnerabilities of extensions. So what can be done about that, apart from typical best practices?
I guess activating SEF URLs and having menu items for that component (at least hidden menu items) will make sure you don't expose all your query parameters to search results. Of course that does not hinder SQL injections, but at least you masquerade your used extensions.
Besides, it's interesting to simply google the component's name (com_xxx). If a lot of pages about exploits come up, check the version exploited and fare carefully.
There are nice tweaks in the video from Brian Teeman about SQL injection. They sure help, but you shouldn't feel to safe following these practices:
Changing the default jos_ DB prefix doesn't help if SQL injection queries use the #__ placeholder instead of jos_.
Removing user id 62 or username 'admin' does not help if the injection query can use the group field (group='super administrator') with a LIMIT 1.
That's it for me, hope you can use that info!
The interesting part is how they found the website. I stumbled upon the top search keywords in Google Webmaster Tools and found out that lots of queries were like "option=com_...." (extension name blanked out).
One simply cannot know about all vulnerabilities of extensions. So what can be done about that, apart from typical best practices?
I guess activating SEF URLs and having menu items for that component (at least hidden menu items) will make sure you don't expose all your query parameters to search results. Of course that does not hinder SQL injections, but at least you masquerade your used extensions.
Besides, it's interesting to simply google the component's name (com_xxx). If a lot of pages about exploits come up, check the version exploited and fare carefully.
There are nice tweaks in the video from Brian Teeman about SQL injection. They sure help, but you shouldn't feel to safe following these practices:
Changing the default jos_ DB prefix doesn't help if SQL injection queries use the #__ placeholder instead of jos_.
Removing user id 62 or username 'admin' does not help if the injection query can use the group field (group='super administrator') with a LIMIT 1.
That's it for me, hope you can use that info!
Views: 56
-
Comment by Martin Rasser on October 14, 2009 at 2:20pm
-
@Brian: I hope my post didn't come out as a criticism to your suggestions. They are very good and I decided to follow them from now on. I just wanted to point out where they won't help.
About the #__ thing: Probably no scripts ever used #__, but as long as the query goes through replacePrefix() and the #__ does not end up in quotes or double-quotes you still get what you want. I even went through this wacky replacePrefix() method to confirm that.
-
Comment by Matt Thomson on October 14, 2009 at 4:21pm -
Hi Martin,
Your post seems 100% correct to me. I had a sql injection flaw when I was a noobie at making extensions:
http://www.milw0rm.com/exploits/6723
It was the case that the hackers googles com_igallery and the ones in the top 20 seemed to get hacked first, and the ones further down googles list came later.
I can't see how having the #__ makes any difference to security, if someones going to put nast sql in a unesacaped $var, Joomla will excecute it, #__ makes no difference.
Suprisingly people who had the good old magic quotes on were probably protected, although I do agree with the advice its best to learn how to code properly rather than rely on things like this.
I'm not sure if Google lets you do a HTML search, if they/ someone else did, someone could seach for class="igallery" and get the same result, regardless of sef urls. I haven't heard of any search engines that do this though.
-
Comment by Matt Thomson on October 14, 2009 at 4:24pm
-
Actaully on a second look magic quotes wouldn't do much as the injection doesn't use any quote marks.
-
Comment by Matt Thomson on October 14, 2009 at 4:36pm
-
I remember after the drama I contacted the JED and asked them to make a checkbox that says "I have read and understand this page":
http://docs.joomla.org/Tutorial:How_to_make_your_Joomla_addon_more_secure_WIP
Ultimately it is the developers responsibilty, not the JED's, but my flaw simply came from none of the tutorials I done clearly explaining security and how important it is (Not looking at anyone in particular Joseph Leblanc!). If anywhere along the way some page had said "Hey, This Is Important, You Must Do These 4 Things (SQL, XSS, Globals, Remote File Inclusion)" in big red writing, a lot of sites would never have got hacked.
Of course I am still waiting on JED's reply....
-
Comment by Amy Stephen on October 14, 2009 at 5:02pm
-
Good piece, Martin.
That's not a bad idea - to add a prompt like that. Peter is recently added to JED. Might leave him a profile message.
Also, Martin, I wanted to say that adding 301 redirects to home page for any parametrized values when you use SEF is not only a good way to reduce duplicate content but also a way to enhance security by making certain robots are not able to read that information. *For developers only*, this "starter router overrides" I shared is a good start on trapping those option parameters and redirecting.
Brian's Secrets videos talks about not wanting unintended content on the site. The same holds true for not allowing unintended URLs. Your Web site Design process should include intentional URL design and I encourage the use of custom plugins to trap, record, and redirect unintended paths.
-
Comment by Matt Thomson on October 14, 2009 at 6:21pm
-
Hi Brian,
I am not sure what point you are making. There are dozens of poeple blogging about Joomla, and I'm guessing each blog gets read by a very small minority of Joomla noobie developers, let alone those Joomla Noobies who know about the tracker. Are you suggesting that because you made some obsecure post that somehow new developers are now informed?
This is why I suggested putting a checklist on the JED, almost all developers submit their extensiosn here, so it at least makes all deveopers aware of the issues.
I just had a friend who messaged me the other day asking if JRequest::getVar protects from sql injections, he didn't know about the Joomla docs security page, and he is close to submitting the extension. This information is not clear enough.
Us more experienced developers aren't doing enough to get the security message out there, and I hope it isn't the case you think blogging about being a dork is enough, a bit ironic if that is the message.
-
-
Matt - you didn't read the entire post, did you? Pretty sure Brian is agreeing with you. :-)
-
Comment by C O'Shea on October 14, 2009 at 8:10pm -
there should also be a "this is vulnerable!" button in the JED so that it can be removed pending securing
-
-
@Matt: Brian was just poking at the public xml files, exposing extension info, he's not calling anybody a dork.
@Amy: Sending any URL with parameters to the homepage might get you in trouble. Even with SEF active you can have parameters in extensions (e.g. for pagination). URIs look something like this then: /menuitem/category?start=3. And creating routers accounting for all these little parameters for a component would be quite some work that gives you more pitfalls than advantages.
I was thinking about creating a small plugin that simply takes the URL, sees if it's a non-SEF, puts it through JRoute::_() and if the result is different, do a 301 redirect. That would solve SEF/non-SEF duplicate content issue (and probably creates havoc in combination with JoomFish, sh404SEF etc, but I guess that can be worked out).
-
-
@caeos: This is already happening. Extensions are pulled if there are serious security flaws.
© 2012 Created by Amy Stephen.
You need to be a member of All Together, As A Whole to add comments!
Join All Together, As A Whole