Radiant Site Hacked


#1

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 L.
http://wiseheartdesign.com


#2

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:


#3

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: removed_email_address@domain.invalid
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant


Andrea F.

removed_email_address@domain.invalid
http://bigchieflabs.com/blog/
http://think.bigchief.it


#4

Andrea F. 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


#5

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.


#6

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


#7

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 M.


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

————————————————————
Q: Why is this email 5 sentences or less?
A: http://five.sentenc.es


#8

On 23 Jul 2007, at 4:01 PM, Erik M. 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 M.

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


#9

Andreas S. 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 L.
http://wiseheartdesign.com


#10

Honestly we should be storing the id and not the whole object in the
session. Good catch!

Sean


#11

Il giorno 23/lug/07, alle ore 15:44, Sean C. 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 :slight_smile:
I only made a thought about the class variable…but now I understood
that it’s not a problem…thank u :wink:


#12

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 L.
http://wiseheartdesign.com

Hi John,

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

I found the security hole.

Sylvain


#13

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 D. 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 D. 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 L.
http://wiseheartdesign.com


#14

Thanks for the update and details John.