Joomla! Discussion Forums

Thanks for this solution!

Phil...

Do you know EVERYTHING???

Let's get together and talk about tomorrow's lottery numbers, ok? 

Another positively GREAT idea -- not only for the CSRF reported in this thread, but for browser-based administration in general.. this is a must have!

Thank you again!

I was always called a "know-all" but I thought people were just taking the mic out of me as I was growing up 

Honestly though - I have been around these parts a long time... ...

@masterchief:
I think maybe a slightly different "MINDSET" may be needed here.

Instead of  only trying to "wall off " forms with tokens and/or captha (which we will still use, btw) we move to GREATER DISCLOSURE of application workings!

example.
In the same way that "WHO'S ONLINE" tell's you who's online (and in the case of SMF, what they are doing) lets have an ACTIVITY LOG for the ADMIN CONSOLE, and an AUTHENTICATOR/GATEWAY MONITOR for all applications

(since each request passes through the index.php (the gateway), we could have a configurable setting , doing a qualified lookup on the status of the "option" variable to see if it is turned on or not!

In fact, logically, we could even use this provision to force captha for one function vs another, or one USER vs another.


ie.

get request var
lookup admin (or other function in permissions database)
|
|  currently enabled for this user/Ip address/action---No?-->exit
|
| allowed
|
Captha required?
|---Yes-- insert captha routine
|
allow module to execute
|
|


Note, this would allow us to TURN OFF creation of admin accounts, user account creation or even making changes to server configuration
!



i dunno about using prism. It seems like overkill to install a complete new application to address one vulnerability, especially as there are other app specific vulnerabilities exposed on the front end as well.

all Prism is, is a 'custom browser' dedicated to ONE url, but - being a browser, and a compatible one at that, then it's exposed and liable to the same vulnerability vectors as any of the others.

furthermore, the internet is by nature interconnected and your site may NEED to  connect to and interact with external applications anyway (i.e. Google maps, spelling applications, ASKIMET etc.)

Could you use CSRF to create new content (Frontpage) items, and deface a site that way?
eg, create a frontpage article, and post it to the site? ( and potentially embed scripts to do even more actions?)
I mean, there could be more exposure than just the 'back end create admin user isssue'

look like we WILL need some kind of Captha and maybe loggin/email issue,
i.e. Main Admin gets an email whenever some administrative tasks are performed (we'll probably have to disable changing of the admins email address in that case!)

(Istnt it a PITA how ostensibly straight forward changes seem to grow exponentially with an almost recursive demand to touch all kinds of code?? - dont even get started on the accessibility and translation/documentation overhead of all this!)

Not to be pedant...
Phil's solution is good...but it's no more than using 2 different browsers: one *only* to start the session for the administratio backend, another to browse the internet. This could be done with two different profiles of the same Firefox or just using IE and Firefox.
In the end prism is built with xul and embeds firefox xpcom's so it's practically 99% similar to using 2 firefox different profiles at least for what concerns this thread and the csrf vuln.
It's just my opinion, not meant to go against the know-all phil and his business, in the end he was the only to help in this thread.

Don't worry, A lot of people fail to see the full potential of Prism/webrunner at the moment - and you are right, it is like running another browser - but it is an instantly available solution (And remember that Joomla Users are not all power users - there are some Joomla admins that find it hard to turn on their PC!)

Prism is still in very early development as a new platform, and has massive potential to be a real contender in the future to bring web apps back to the desktop.

Yes definately, the future is web apps taken on the desktop, Adobe has created something similar but with a lot of API's and a complete new framework, in which client and server communicate using remote calls with desktop-like interface. Ajax was the first step on real time interaction and desktop web app will be the final step...but much more must be done on server side I believe, at now your solution is a browser and a handy link on the desktop, but still effective for our issue.

Just because joomla is not run by power users Joomla itself must be secure off-the-shelf, since we cannot hope that every admin uses all such (even if simple) practices to login into their admin panel, they are just used to double click on the nasty e or on the good fox and login.

Anyway, prism is a good simple solution

ZINHO!


you owe me a new KEYBOARD/Monitor!!!



(apparently others have the same response to your bold assertion!)



The problem with Joomla and just about all other web apps for that matter is often more 'mind' security than 'code' security... people just cant ( or wont) conceive of attack vectors or limited in their security implementation's and responses.

For instance, the common model used is the Microsoft Model.

Once you have logged in, you have full and complete access to everything!

Whereas other apps have different levels of access and different authentication required depending how critical the action you want to execute.

It is not just enough to say...

USER=super admin - allow creation of multiple super admin users.

The action: "Create Super Admin User" must be viewed in the context of...

1. what is the security implication of this action.
2. How often is it likely to be performed during site lifetime.
3. Would demanding re authentication significantly impact work flow, usability and accessibility in a manner that does not justify the security gains?

viewed against that checklist, demanding a CAPTHA for .."load module, component, template,add Admin user,change template" while not requiring one for .. "block user (non-admin), upload image) is an easy choice to make.


I believe CAPTHA integration in Joomla is LOOOONG over due.

Another functionality needed as well, is admin activity login.
I've implemented a crude log by dumping IP, username, useragent, requestURI and POST /request variables etc on EACH pageload of administrator\index*.php

Cariboo, Did you spit/puke on your monitor? 

I said that prism is a simple solution for the csrf issue, but hardly believe it will spread to protect ppl. ppl is lazy and wants a secure base code.
You cannot teach ppl security approach, it just doesn't work. Years of failed attempts and efforts in such direction demonstrate it.

And yes, there is much to do in the backend to make it more secure. For example vbulletin asks your password again for every critical operation you're trying to do. Vbulletin just doesn't mind of you having a valid session. This should be considered as a new feature.
Then I guess that a little less of ajax and a bit more of security is the fair price to pay in the backend. Many problems are there to secure every piece of asyncronous call....

And cariboo, you seem to make use of some substances before you hit post...I don't always understand your huge responses, but maybe it's the english not being my mother-tongue. 

Rubbish! Captcha (Spelt right) is nothing more than a pain - and can be VERY easily defeated and relies on server based image manipulation programs which you cannot assume every server has installed/enabled (Like GD for example).



This is more workable - phpBB asks for the admin password as well when you want to go to the admin console - this is a more workable solution, however you have to define exactly what a "critical operation" is - else you will be asking for the password far too often.

For example, which of these is a "critical operation"?

-- Creating a super user
-- Deleting Content
-- Publishing an article
-- changing the list length
-- viewing system configuration
-- reordering the frontpage
-- Adding a new menu item

See its not easy to to define "critical operation" :-) Although the concept is a good one.


There is a fine balance between a workable solution and something that is going to become a pain.

A good captcha and a token in alternative or in addition is a basic protection for most of the site, assuring a high percentage of protection.
Plus adding authentication on user addition and to anything that can add code to pages or even worse files (like extensions installation panel) must be considered critical. Google and Amazon are using captcha and a good session management to defeat csrf and they're fine.
And you can guess thousands of people trying to attack them every single day.

I
//
//
//  Run this script from the PowerBuilder development environment.  The
//  display of qualifying records need to be 'filtered' to only include those records
//  with the starting fiscal period as the current fiscal period.  The
//  resultant records shall be saved as an MS Excel spreadsheet and
//  forwarded to Finance for distribution to the appropriate sites.
//
I'll see your 'Rubbish' and raise you one 'BALDERDASH!'
1. you may be  assuming that CAPTCHA *has* to be implemented as visual strings rendered as a graphic, where it can be rendered easily as series of images (pick the ugliest) or audio -"what animal is that?" or any combination!
Ideally, the CAPTCHA model that Joomla implements can be plug and play, switchable in or out (so there wont necessarily be a fixed target to code for) AND there can be a back end configurable modifier that can be applied ( a secret algorithim as it were: Add last two digits of current Minute to the expected response
CAPTCHA graphic says.. 45LETMEIN ... you KNOW to add "0:12AM" to whatever you see, resulting in 45LETMEIN0:12AM ... This is just an example, there are obvious time synchronization issues, lol)

On top of that, you log failures and or attempts in general. (It makes no sense to have a FENCE AROUND YOUR PROPERTY if you dont have a BARKING DOG (even a puppy)
the "barking dog" alerts you to an intruder attempt  (or too strong CAPTCHA )

ACCESSIBILITY/USABILITY shouldnt be a prob, because we are really talking about the back end implementation  for YOU so you can modify the algorithim, use audio if you like, be sports specific..the possibilities are endless.

As far as your "Are these SECURE ITEMS?" list, I would say all of them are. I've been able to implement a 'recycle bin' of sorts for my content items by mucking with the DELETE code, so it saves the item id as something else, changes it, then indicates a new 'published' status, making it disappear.

I do the same for edits as well, so I can go back to different versions and all would be saved.
I figured its easier to do that, rather than discipline/haggle with mods because they made untoward content changes..just revert the darn thing..

Light heart as it might be, let's control ourself and refrain from further spitting on monitors. Cariboo, I'm talking to you in particular.

We will be calling for input for 1.6 so I suggest you all get your thinking caps on and start preparing some discussion papers on what you see are the problems (and there are obviously some different points of view) and how you would implement solutions (with equally varied ideas it seems).

I'll give you some latitude and let the line of debate continue, but please respect that while everyone has a right to be heard, not everyone will necessarily agree with you.  If you are all ok with that, by all means please continue because I am actually liking some of the thinking that is now coming through (I like the fence and barking dog analogy).  Keep in on the topic of CRSF though, please.

An interesting forum post!
http://powersellersunite.com/post-135510.html

I have emailed them for more details ...

Hello Phil Taylor
Very informative information on your blog and thanks for keeping everyone up to date.  I know server Joomla sites that have been hacked.  This is a serious issue and there definitely needs to be an official patch released for 1.0.13.  If I can be of any assistances please let me know.

Thanks Phil.
I will add two more things:
- NEVER read emails (don´t even use email-programs) while logged in to Joomla Admin
- NEVER use browser-based RSS-feed readers while logged in to Joomla Admin

yes those two are good advice, and can be summed up by saying "dont go near any other html rendering subsystem" :-) :-)

Will all of us with alot of customers on 1.13 sites soon be able to patch to a 1.13 security patch or likewise so we can rest assured thier sites are safe?

Imo a month + and no official security patch is _NOT_ a viable way of prioritizing whats important.

If existing joomla security is prioritized below the release of a new version with no relation to the old one, then the people that object that open source is bad due to security might just be right in the long run :/

@tresan, testing of the SVN release of 1.0 is being organised at the moment.  Another minor security problem with a third party library also came in yesterday so we are fixing that as well.  I can't give you an end date but the release process has started.  All I can say is that it will take as long as it takes to ensure we aren't creating more problems than we solve given the sheer number of 1.0 sites out there - been there, done that, don't want to do it again.

Please note tough, that this problem is not peculiar to Joomla!.  Basically everyone is going to have to change their browsing habits in general.  We can only make it "so" difficult for attackers, but nothing is foolproof unfortunately.

We can also add to the above lists of good practice to use Remember Me (on any site) with caution or not at all.

Hi masterchief,

>> "this problem is not peculiar to Joomla!.  Basically everyone is going to have to change their browsing habits in general."

Does this mean that *every* CMS, shopping cart, etc using cookie authentication should:

- ALWAYS click LOGOUT in Joomla Admin when you finish
- NEVER browse other websites while logged in to Joomla Admin
- If you allow users to upload/modify your site through any third party component then don’t browse/or limit your surfing of your own site while logged in to Joomla Admin
- NEVER click on links to “Upgrade this component” in 3rd Party Components
- NEVER browse forums while logged into Joomla Admin
- NEVER read emails (don´t even use email-programs) while logged in to Joomla Admin
- NEVER use browser-based RSS-feed readers while logged in to Joomla Admin
- use Remember Me (on any site) with caution or not at all.

If so, this is a very significant development and will require a huge amount of user education (for all cookie based systems). For a start I'd assume that many people have another tab/window open when making changes to their site.

Thanks

Yes - this has always been the case. 

Its not just cookie authentication, its session management.

Difference is that now that this type of web vulnerability is well known and popular in the news more hackers will try to exploit it, before it was time bomb :-) Even Amazon and Gmail had CSRF issues ;-)

Opening the tab is not the problem - stay there do your business and log out - that's all we are saying.

But yes, it's a huge step in education.  Basically it's one of those "but mum says we shouldn't go down that street" kind of things.  There are places you don't go in real life, there are things you don't do.  This is no different to educating people about keeping their credit cards, passports, houses, cars (don't leave the car unattended with the keys in the ignition), etc, secure.  The reality is the web is no more or less safe than the real world.

OK thanks Phil, thanks masterchief.

I think I'm getting my head around this. I guess I need to change my behavior radically - I usually have many tabs open at once (including authenticated sessions for webmail, site admin, etc) as well as my Exchange email and often browse around at the same time.

Looks like those days are over.

Cheers

While we are waiting for the security patch for 1.0.x, we can edit our Joomla site for example with Firefox and paralelly we can browse another sites with another type of browser, for example Internet Explorer. None of these can access the cookies of another type of browser. 

exactly

Hello ppl! Great working on finding this vulnerability out and the patches and fixes so far...

I'm an admin in a brazilian Joomla community with 6.000+ members and we would be very glad if any of you could explain this bug in simple terms so all of them/us could understand what this threat really is...

Thank you very much!

Congratulations!

Rick

Rick

While I share your concern, I do not believe "spelling it out" is in the best interests of all involved - you included - too much has already been shared (IMHO) about the exact concepts of this vulnerability in this thread.

We I would recommend that you follow the advice posted in this thread - to minimize the risk of being caught out.


If you need to know what a CSRF is then google is your friend - If you cant work out how that would apply to Joomla then (with respect) you are probably not going to need that knowledge anyway :-) :-)

I'm sure that the Joomla Core Dev team will make another release of Joomla 1.0.x soon !

Kindest regards
Phil.

Ok, the  advices were already translated/posted in my community when I posted this question here...

So I think I'll just tell them to wait and not worry about it, right?

Thank you!!!

Rick

I just wanted to bring to all yours attention that the issue is leaving the Joomla community. The most important German PC magazine published an article on their homepage. Here is the English version: http://www.heise-security.co.uk/news/101676.

Many people have to answer a lot of questions from customers now. This shows how important quick actions are!

Rooney

Rooney, the vulnerability is all over the net since I published it all over the net 15 days ago...it is even on press magazines.



Well, I published it *afte* the patch for 1.5 was released, that is after actions was taken...

You're a bit out of time with your post...