# Radiant Site Hacked **URL:** \ **Category:** Radiant CMS\ **Created:** [July 23, 2007, 2:03am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096 "2007-07-23T02:03:38Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 23, 2007, 2:03am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/1 "2007-07-23T02:03:38Z")
This is just an FYI, but in the interests of full disclosure you should be aware that the main Radiant site ([http://radiantcms.org](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](http://wiseheartdesign.com) ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 23, 2007, 12:06pm UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/2 "2007-07-23T12:06:58Z")
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: ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 23, 2007, 3:01pm UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/3 "2007-07-23T15:01:07Z")
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/](http://radiantcms.org/mailing-list/search/) > Site: [http://lists.radiantcms.org/mailman/listinfo/radiant](http://lists.radiantcms.org/mailman/listinfo/radiant) * * * Andrea F. removed\_email\_address@domain.invalid [http://bigchieflabs.com/blog/](http://bigchieflabs.com/blog/) [http://think.bigchief.it](http://think.bigchief.it) ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 23, 2007, 3:19pm UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/4 "2007-07-23T15:19:51Z")
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. > **[The Cost of Static](https://thedailywtf.com/articles/The_Cost_of_Static)** > > In the height of the offshore-outsourcing craze, "Steve" worked for a company that had a flagship application which managed, among other things, performance-related documents about employees. With labor being so inexpensive, the company decided to... ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 23, 2007, 3:50pm UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/5 "2007-07-23T15:50:32Z")
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. ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 26, 2007, 12:45am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/6 "2007-07-26T00:45:48Z")
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 ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 26, 2007, 12:45am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/7 "2007-07-26T00:45:50Z")
> > 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/](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 > **[腾博会官网诚信为本|腾博tengbo9885登录](http://www.gravelroadstudios.com/)** > > 腾博官网诚信为本9885竞猜提供真人、体育、电子、彩票、棋牌等娱乐服务,支付秒到账,客服7 X 24小时在线,让您畅快游戏!! (857) 222-6852 ———————————————————— Q: Why is this email 5 sentences or less? A: [http://five.sentenc.es](http://five.sentenc.es) ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 26, 2007, 12:45am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/8 "2007-07-26T00:45:51Z")
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/](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 ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 26, 2007, 12:45am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/9 "2007-07-26T00:45:54Z")
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](http://wiseheartdesign.com) ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 26, 2007, 12:46am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/10 "2007-07-26T00:46:00Z")
Honestly we should be storing the id and not the whole object in the session. Good catch! Sean ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 26, 2007, 12:46am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/11 "2007-07-26T00:46:33Z")
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 🙂 I only made a thought about the class variable…but now I understood that it’s not a problem…thank u 😉 ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 26, 2007, 9:14pm UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/12 "2007-07-26T21:14:20Z")
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](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](http://wiseheartdesign.com) Hi John, Contact me at my email address cptflam [at] [gmail.com](http://gmail.com) - I found the security hole. Sylvain ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 27, 2007, 2:48am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/13 "2007-07-27T02:48:53Z")
Sylvain Gibier wrote: > Contact me at my email address cptflam [at] [gmail.com](http://gmail.com) - > > I found the security hole. Sylvian did indeed find a security hole in the [radiantcms.org](http://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](http://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: 2. Then he opened up another tab an initialized a new session hitting this URL: 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: 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: [TextDrive Weblog: On Rails sessions](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](http://wiseheartdesign.com) ---
**Author:** ![John\_WSLong](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/34f0e0/32.png) [@John\_WSLong](https://www.ruby-forum.com/u/John_WSLong)\ **Post date:** [July 27, 2007, 3:36am UTC](https://www.ruby-forum.com/t/radiant-site-hacked/110096/14 "2007-07-27T03:36:56Z")
Thanks for the update and details John.