Forum: Radiant CMS Radiant Site Hacked

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
6ec6f77ea603dd75b3a7a7775b059e79?d=identicon&s=25 John W. Long (Guest)
on 2007-07-23 02:03
(Received via mailing list)
This is just an FYI, but in the interests of full disclosure you should
be aware that the main Radiant site (http://radiantcms.org) was
exploited on May 15th this year. The attacker added an invisible link on
the homepage to another Web site. At the moment we don't know if this
was the result of an exploit on the Radiant CMS software itself, or if
the attacker used some other means. In either case the attacker managed
to create an admin user for himself and add his link to the homepage
layout. I was only made aware of the problem late last night and we are
still looking into it.

Has anyone else been the victim of an attack on a Radiant Web site? Can
anyone shed light on how the attacker would be able to do this?

--
John Long
http://wiseheartdesign.com
81d060797f61976a0703b995825963fd?d=identicon&s=25 Edwin V. (edwin-v)
on 2007-07-23 12:06
(Received via mailing list)
Yesterday, I noticed something in the Radiant code. You are using a
class variable in an observer to store the current_user. Using class
variables in Rails is always bad, because a class is used by more
then one user once loaded in production mode. I experienced a lot of
problems with this in the past.

I can't say if this might cause the exploit, but the code could cause
race conditions which might give users access to the wrong information.

Edwin Vlieg


Op 23-jul-2007, om 2:02 heeft John W. Long het volgende geschreven:
D03835ee1210e4251e8c1a3976a38bc5?d=identicon&s=25 Andrea Franz (Guest)
on 2007-07-23 15:01
(Received via mailing list)
I've not been victim of an attack...but I think it could be better
setting the current_user in a thread variable instead of using a
class variable.

I usually use something like this:

def set_current_user
   Thread.current['current_user'] = current_user
end






Il giorno 23/lug/07, alle ore 12:05, Edwin Vlieg ha scritto:

> Edwin Vlieg
>> was the result of an exploit on the Radiant CMS software itself,
>> anyone shed light on how the attacker would be able to do this?
> _______________________________________________
> Radiant mailing list
> Post:   Radiant@lists.radiantcms.org
> Search: http://radiantcms.org/mailing-list/search/
> Site:   http://lists.radiantcms.org/mailman/listinfo/radiant



-----
Andrea Franz

andrea@bigchief.it
http://bigchieflabs.com/blog/
http://think.bigchief.it
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-07-23 15:19
Andrea Franz wrote:
> I've not been victim of an attack...but I think it could be better
> setting the current_user in a thread variable instead of using a
> class variable.
>
> I usually use something like this:
>
> def set_current_user
>    Thread.current['current_user'] = current_user
> end

That would only work if each request had its own thread. But Rails
doesn't even use threads at all.

http://worsethanfailure.com/Articles/The_Cost_of_Static.aspx
3a83969376c805ef5b6042191fdb0ff3?d=identicon&s=25 Andreas S. (andreas)
on 2007-07-23 15:50
John W. Long wrote:
> Can anyone shed light on how the attacker would be able to do this?

Just a guess: Admin::UserController#preferences.

> only_allow_access_to :index, :new, :edit, :remove, :when => :admin,

"preferences" is not in that list.

> @user = User.find(session['user'].id)

Unless whiny_nils is enabled (which I strongly recommend), anyone can
pretend to be user #4, because nil.id = 4.

> if valid_params?

Only password changes allowed, that should be OK for a hacker.

I didn't try it, so I might have overlooked something, but maybe you
should take a look at it.
8802b1fa1b53e2197beea9454244f847?d=identicon&s=25 Sean Cribbs (Guest)
on 2007-07-26 00:45
(Received via mailing list)
Before we jump the gun, we have no _real_ idea how the attack was
accomplished.  The core team is pouring over the log files to find more
information.  I agree that the class-variable thing is kind of bad
practice, but it's set at the beginning of every request (and Rails only
handles one at a time), so there will be no issue with a race condition.

Sean
D21f5af332c92a01f33f161f8915428e?d=identicon&s=25 Erik Mallinson (Guest)
on 2007-07-26 00:45
(Received via mailing list)
> > Can anyone shed light on how the attacker would be able to do this?

If it was anything like the attack on Dreamhost accounts
(http://www.dreamhoststatus.com/2007/06/06/security-breach/) it was
via FTP and it looks like anything resembling an index page for a cms
was hit. My Radiant sites were the only ones that weren't affected
though.

- Erik Mallinson

--
Gravel Road Studios
gravelroadstudios.com
(857) 222-6852

————————————————————
Q: Why is this email 5 sentences or less?
A: http://five.sentenc.es
D380d4fc032b616c978788d8fce7d80e?d=identicon&s=25 Jacques Marneweck (Guest)
on 2007-07-26 00:45
(Received via mailing list)
On 23 Jul 2007, at 4:01 PM, Erik Mallinson wrote:

>>> Can anyone shed light on how the attacker would be able to do this?
>
> If it was anything like the attack on Dreamhost accounts
> (http://www.dreamhoststatus.com/2007/06/06/security-breach/) it was
> via FTP and it looks like anything resembling an index page for a cms
> was hit. My Radiant sites were the only ones that weren't affected
> though.
>
> - Erik Mallinson
>
It could also be someone who has an account on nicola?  Provided that
the database password file is not readable only by the user where the
radiantcms site runs under?

Regards
--jm
6ec6f77ea603dd75b3a7a7775b059e79?d=identicon&s=25 John W. Long (Guest)
on 2007-07-26 00:45
(Received via mailing list)
Andreas Schwarz wrote:
> Just a guess: Admin::UserController#preferences.
>
>> only_allow_access_to :index, :new, :edit, :remove, :when => :admin,
>
> "preferences" is not in that list.
>
>> @user = User.find(session['user'].id)
>
> Unless whiny_nils is enabled (which I strongly recommend), anyone can
> pretend to be user #4, because nil.id = 4.

How would they do that? Hitting the admin/preferences URL when you are
not logged in will redirect you to the login page.

--
John Long
http://wiseheartdesign.com
8802b1fa1b53e2197beea9454244f847?d=identicon&s=25 Sean Cribbs (Guest)
on 2007-07-26 00:46
(Received via mailing list)
Honestly we should be storing the id and not the whole object in the
session.  Good catch!

Sean
D03835ee1210e4251e8c1a3976a38bc5?d=identicon&s=25 Andrea Franz (Guest)
on 2007-07-26 00:46
(Received via mailing list)
Il giorno 23/lug/07, alle ore 15:44, Sean Cribbs ha scritto:

> Before we jump the gun, we have no _real_ idea how the attack was
> accomplished.  The core team is pouring over the log files to find
> more
> information.  I agree that the class-variable thing is kind of bad
> practice, but it's set at the beginning of every request (and Rails
> only
> handles one at a time), so there will be no issue with a race
> condition.
>


Ok I undestrood :)
I only made a thought about the class variable...but now I understood
that it's not a problem...thank u ;)
4209041bb73ed86983c6cee179072a51?d=identicon&s=25 Sylvain Gibier (sylvain_gibier)
on 2007-07-26 21:14
John W. Long wrote:
> This is just an FYI, but in the interests of full disclosure you should
> be aware that the main Radiant site (http://radiantcms.org) was
> exploited on May 15th this year. The attacker added an invisible link on
> the homepage to another Web site. At the moment we don't know if this
> was the result of an exploit on the Radiant CMS software itself, or if
> the attacker used some other means. In either case the attacker managed
> to create an admin user for himself and add his link to the homepage
> layout. I was only made aware of the problem late last night and we are
> still looking into it.
>
> Has anyone else been the victim of an attack on a Radiant Web site? Can
> anyone shed light on how the attacker would be able to do this?
>
> --
> John Long
> http://wiseheartdesign.com

Hi John,

Contact me at my email address cptflam [at] gmail.com -

I found the security hole.

Sylvain
A204ca511ddee820957e715d6d363548?d=identicon&s=25 John W. Long (Guest)
on 2007-07-27 02:48
(Received via mailing list)
Sylvain Gibier wrote:
> Contact me at my email address cptflam [at] gmail.com -
>
> I found the security hole.

Sylvian did indeed find a security hole in the radiantcms.org
configuration. It wasn't a security problem in Radiant per se, but it
was a problem with the way Radiant was configured on my host. However
the hole it uncovered is something that may affect ANY Radiant
application running on a shared host.

To gain access to the admin pages of radiantcms.org Sylvian used Firefox
2.0 with the Web Developer extension which allows you to see the current
cookies for a page. Here is how he got access to the Radiant admin:

1) He first logged on to the admin part of the demo site:

   http://demo.radiantcms.org/admin/pages

2) Then he opened up another tab an initialized a new session hitting
this URL:

   http://radiantcms.org/admin/login

3) He then changed the _session_id cookie to the value used by the demo
site using the Web Developer extension in Fox.

4) With the correct cookie set he could now bypass the login screen and
hit the following URL:

   http://www.radiantcms.org/admin/pages

The reason this worked is that the CGI session stuff is configured by
default to place sessions in /tmp for all Ruby applications. Both the
demo application and the version of Radiant powering the Radiant Web
site were configured to use this default. This effectively meant that
they could share the same sessions the _session_id cookie was set up
correctly.

I fixed the problem by following the advice of this article:

   http://weblog.textdrive.com/article/196/on-rails-sessions

Which recommended that you place the following line in
config/environment.rb:

   ActionController::CgiRequest::DEFAULT_SESSION_OPTIONS.update(:tmpdir
   => File.join(RAILS_ROOT, '/tmp'))

We will probably be switching to ActiveRecord based sessions to avoid
this in the future. In the mean time, people running Radiant sites
should take note of the above ESPECIALLY THOSE USING A SHARED HOST!!!

--
John Long
http://wiseheartdesign.com
C0e931e4c48678091fea86704d835cfb?d=identicon&s=25 d n (Guest)
on 2007-07-27 03:36
(Received via mailing list)
Thanks for the update and details John.
This topic is locked and can not be replied to.