Hi gang,
The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.
I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).
There is no other evidence of other damage at the site that I found in the wake of this discovery.
(Site was using 6.19 at the time of the breach).
I'm stumped. Ideas anyone?
Shai
I had a similar hack happen. I had about 7 comments on a blog, in Russian, from an anonymous user. I have permission set so only registered users can make comments. Hmmm... I deleted them, but wonder what I should do to stop this in the future. I did set capcha so that comments require it. Drupal 6.19. Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 16, 2010, at 9:32 PM, Shai Gluskin wrote:
Hi gang,
The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.
I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).
There is no other evidence of other damage at the site that I found in the wake of this discovery.
(Site was using 6.19 at the time of the breach).
I'm stumped. Ideas anyone?
Shai
[ Drupal support list | http://lists.drupal.org/ ]
Folks: Thanks for the link to the security test. I installed it, BUT, when I was messing with my permissions, so fix various file permissions, I did something very simple that caused an error message all through the site:
--message: user warning: Can't create/write to file '/tmp/ #sql_3cb2_0.MYI' (Errcode: 13) query: SELECT DISTINCT b.* FROM blocks b LEFT JOIN blocks_roles r ON b.module = r.module AND b.delta = r.delta WHERE b.theme = 'solarsentinel' AND b.status = 1 AND (r.rid IN (2) OR r.rid IS NULL) ORDER BY b.region, b.weight, b.module in /home/ wap/public_html/modules/block/block.module on line 433 --end message.
I understand that the error is in permissions for the /tmp directory. I got this error when I changed permissions, but now when I do chmod - R 0777 (as a test), I still get the error. This should set the permissions to "Everybody can do anything". What's up? I'm not a unix expert, but not a novice either and this confuses me. Does the "#" char at the start of the file name mean the file is invisible, ??
Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 16, 2010, at 11:00 PM, prothero wrote:
I had a similar hack happen. I had about 7 comments on a blog, in Russian, from an anonymous user. I have permission set so only registered users can make comments. Hmmm... I deleted them, but wonder what I should do to stop this in the future. I did set capcha so that comments require it. Drupal 6.19. Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 16, 2010, at 9:32 PM, Shai Gluskin wrote:
Hi gang,
The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.
I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).
There is no other evidence of other damage at the site that I found in the wake of this discovery.
(Site was using 6.19 at the time of the breach).
I'm stumped. Ideas anyone?
Shai
[ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
Folks: Not only do I get this error code, but several modules on my site have stopped working. The only thing I did was install the security module and mess with permissions on the /tmp folder. Sheesh! Very frustrating. Bill
William A. Prothero http://earthednet.org/
On Dec 17, 2010, at 10:56 AM, prothero wrote:
Folks: Thanks for the link to the security test. I installed it, BUT, when I was messing with my permissions, so fix various file permissions, I did something very simple that caused an error message all through the site:
--message: user warning: Can't create/write to file '/tmp/ #sql_3cb2_0.MYI' (Errcode: 13) query: SELECT DISTINCT b.* FROM blocks b LEFT JOIN blocks_roles r ON b.module = r.module AND b.delta = r.delta WHERE b.theme = 'solarsentinel' AND b.status = 1 AND (r.rid IN (2) OR r.rid IS NULL) ORDER BY b.region, b.weight, b.module in /home/wap/public_html/modules/block/block.module on line 433 --end message.
I understand that the error is in permissions for the /tmp directory. I got this error when I changed permissions, but now when I do chmod -R 0777 (as a test), I still get the error. This should set the permissions to "Everybody can do anything". What's up? I'm not a unix expert, but not a novice either and this confuses me. Does the "#" char at the start of the file name mean the file is invisible, ??
Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 16, 2010, at 11:00 PM, prothero wrote:
I had a similar hack happen. I had about 7 comments on a blog, in Russian, from an anonymous user. I have permission set so only registered users can make comments. Hmmm... I deleted them, but wonder what I should do to stop this in the future. I did set capcha so that comments require it. Drupal 6.19. Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 16, 2010, at 9:32 PM, Shai Gluskin wrote:
Hi gang,
The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.
I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).
There is no other evidence of other damage at the site that I found in the wake of this discovery.
(Site was using 6.19 at the time of the breach).
I'm stumped. Ideas anyone?
Shai
[ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
On 17. 12. 2010 20:04, prothero wrote:
Folks: Not only do I get this error code, but several modules on my site have stopped working. The only thing I did was install the security module and mess with permissions on the /tmp folder. Sheesh! Very frustrating. Bill
I do not think you could mess your site just with changing /tmp permissions and reverting it back. I just tried it in one of my vservers (did backup before, of course), and site is working. You must have changed something else too...
btw, my /tmp is "drwxrwxrwt 4 root root". Check yours!
Jarry
--message: user warning: Can't create/write to file '/tmp/#sql_3cb2_0.MYI' (Errcode: 13) query: SELECT DISTINCT b.* FROM blocks b LEFT JOIN blocks_roles r ON b.module = r.module AND b.delta = r.delta WHERE b.theme = 'solarsentinel' AND b.status = 1 AND (r.rid IN (2) OR r.rid IS NULL) ORDER BY b.region, b.weight, b.module in /home/wap/public_html/modules/block/block.module on line 433 --end message.
I understand that the error is in permissions for the /tmp directory. I got this error when I changed permissions, but now when I do chmod -R 0777 (as a test), I still get the error. This should set the permissions to "Everybody can do anything". What's up? I'm not a unix expert, but not a novice either and this confuses me. Does the "#" char at the start of the file name mean the file is invisible, ??
Fixed! The /tmp dir is not the one I thought it was. It's at the root directory of the entire web site. Doh...., the file paths it gave me were the absolute paths relative to server root, not the /tmp that was in my /home/public_html/.... etc directory. It now works, but I truly didn't change it. The security module may have done something.
I'm wondering if it's secure to have the /tmp dir writeable for everyone. Drupal gives me the error unless it is. Or, perhaps I need to figure out the group that mysql is part of. The only groups I have are: root bin daemon sys adm disk wheel
Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 17, 2010, at 11:22 AM, Jarry wrote:
On 17. 12. 2010 20:04, prothero wrote:
Folks: Not only do I get this error code, but several modules on my site have stopped working. The only thing I did was install the security module and mess with permissions on the /tmp folder. Sheesh! Very frustrating. Bill
I do not think you could mess your site just with changing /tmp permissions and reverting it back. I just tried it in one of my vservers (did backup before, of course), and site is working. You must have changed something else too...
btw, my /tmp is "drwxrwxrwt 4 root root". Check yours!
Jarry
--message: user warning: Can't create/write to file '/tmp/#sql_3cb2_0.MYI' (Errcode: 13) query: SELECT DISTINCT b.* FROM blocks b LEFT JOIN blocks_roles r ON b.module = r.module AND b.delta = r.delta WHERE b.theme = 'solarsentinel' AND b.status = 1 AND (r.rid IN (2) OR r.rid IS NULL) ORDER BY b.region, b.weight, b.module in /home/wap/public_html/modules/block/block.module on line 433 --end message.
I understand that the error is in permissions for the /tmp directory. I got this error when I changed permissions, but now when I do chmod -R 0777 (as a test), I still get the error. This should set the permissions to "Everybody can do anything". What's up? I'm not a unix expert, but not a novice either and this confuses me. Does the "#" char at the start of the file name mean the file is invisible, ??
-- _______________________________________________________________ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted. -- [ Drupal support list | http://lists.drupal.org/ ]
On Fri, Dec 17, 2010 at 1:10 PM, prothero prothero@geol.ucsb.edu wrote:
change it. The security module may have done something.
The security module only reports information, it doesn't change or try to fix anything.
Cheers, Greg
-- Greg Knaddison | 720-310-5623 | http://growingventuresolutions.com Mastering Drupal | http://www.masteringdrupal.com
Thanks for everybody's comments. I did change the /tmp directory permissions, inadvertently. I only use unix command lines rarely, and realize that I did a chgrp xyz /tmp, which changed the root folder, rather than the one I thought I was changing.
So, no blame for the security plugin. Thanks for the hints and comments, Bill
William A. Prothero http://earthednet.org/
On Dec 17, 2010, at 12:33 PM, Greg Knaddison wrote:
On Fri, Dec 17, 2010 at 1:10 PM, prothero prothero@geol.ucsb.edu wrote:
change it. The security module may have done something.
The security module only reports information, it doesn't change or try to fix anything.
Cheers, Greg
-- Greg Knaddison | 720-310-5623 | http://growingventuresolutions.com Mastering Drupal | http://www.masteringdrupal.com -- [ Drupal support list | http://lists.drupal.org/ ]
you might be running in a mode that doesn't serve 777 files, try changing them to only allow the webserver to read, write execute, and anonymous to only read. hope that helps.
On Fri, Dec 17, 2010 at 7:04 PM, prothero prothero@geol.ucsb.edu wrote:
Folks: Not only do I get this error code, but several modules on my site have stopped working. The only thing I did was install the security module and mess with permissions on the /tmp folder. Sheesh! Very frustrating. Bill
William A. Prothero
On Dec 17, 2010, at 10:56 AM, prothero wrote:
Folks: Thanks for the link to the security test. I installed it, BUT, when I was messing with my permissions, so fix various file permissions, I did something very simple that caused an error message all through the site:
--message: user warning: Can't create/write to file '/tmp/#sql_3cb2_0.MYI' (Errcode: 13) query: SELECT DISTINCT b.* FROM blocks b LEFT JOIN blocks_roles r ON b.module = r.module AND b.delta = r.delta WHERE b.theme = 'solarsentinel' AND b.status = 1 AND (r.rid IN (2) OR r.rid IS NULL) ORDER BY b.region, b.weight, b.module in /home/wap/public_html/modules/block/block.module on line 433 --end message.
I understand that the error is in permissions for the /tmp directory. I got this error when I changed permissions, but now when I do chmod -R 0777 (as a test), I still get the error. This should set the permissions to "Everybody can do anything". What's up? I'm not a unix expert, but not a novice either and this confuses me. Does the "#" char at the start of the file name mean the file is invisible, ??
Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 16, 2010, at 11:00 PM, prothero wrote:
I had a similar hack happen. I had about 7 comments on a blog, in Russian, from an anonymous user. I have permission set so only registered users can make comments. Hmmm... I deleted them, but wonder what I should do to stop this in the future. I did set capcha so that comments require it. Drupal 6.19. Regards, Bill
William A. Prothero http://earthednet.org/
On Dec 16, 2010, at 9:32 PM, Shai Gluskin wrote:
Hi gang,
The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.
I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).
There is no other evidence of other damage at the site that I found in the wake of this discovery.
(Site was using 6.19 at the time of the breach).
I'm stumped. Ideas anyone?
Shai
[ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
A couple shots in the dark here -
* What roles have "administer comments" rights? * Are there any VBO-based comments administration views on the site? * How secure is the site's database? Is root access still available? If so, is the password secure? * Is phpMyAdmin installed on the site? That can be a weak spot. * Do the Apache logs from the time of the breach show anything odd/curious ?
Also, at the risk of stating the obvious, I'd strongly recommend creating a superuser role and retiring your UID1 account for everything but upgrades/updates.
Cheers,
Bill
On 12/16/10 9:32 PM, Shai Gluskin wrote:
Hi gang,
The author and URL of an anonymous comment was changed about three months after the comment was originally posted. The change happened last week. The new name was in Chinese and the URL is to a Chinese web site. The content of the comment was not changed.
I've never had anything like that happen before. After I discovered this I changed user/1 pw (that is the only account on the site with admin privileges).
There is no other evidence of other damage at the site that I found in the wake of this discovery.
(Site was using 6.19 at the time of the breach).
I'm stumped. Ideas anyone?
Shai
On Fri, Dec 17, 2010 at 12:20 AM, Bill Fitzgerald bill@funnymonkey.com wrote:
- What roles have "administer comments" rights?
- Are there any VBO-based comments administration views on the site?
- How secure is the site's database? Is root access still available? If so,
is the password secure?
- Is phpMyAdmin installed on the site? That can be a weak spot.
- Do the Apache logs from the time of the breach show anything odd/curious ?
All sage advice and good questions.
Also, at the risk of stating the obvious, I'd strongly recommend creating a superuser role and retiring your UID1 account for everything but upgrades/updates.
I think it's not so obvious and not really useful. If the "superuser role" has the permission to "administer users" or "administer permissions" then any user in that role has the exact same permissions as UID1. The only difference is, as you state running update.php (in D7 that distinction is gone - anyone with the right permission can run update.php).
The idea that "uid1 = unsafe" is a security myth that needs to die. There are other more likely avenues of attack such as incorrectly configured input formats.
For those interested, you can test your input formats against security best practices by trying out http://drupal.org/project/security_review
Cheers, Greg
On 17/12/10 09:10 -0700, Greg Knaddison wrote:
For those interested, you can test your input formats against security best practices by trying out http://drupal.org/project/security_review
Very nice module!
regards Rolf
For those interested, you can test your input formats against security
best practices by trying out http://drupal.org/project/security_review
nice, thanks
:ryan
bayousoft.com http://www.bayousoft.com twitter.com/bayousoft http://www.twitter.com/bayousoft
On Fri, Dec 17, 2010 at 10:10 AM, Greg Knaddison < Greg@growingventuresolutions.com> wrote:
On Fri, Dec 17, 2010 at 12:20 AM, Bill Fitzgerald bill@funnymonkey.com wrote:
- What roles have "administer comments" rights?
- Are there any VBO-based comments administration views on the site?
- How secure is the site's database? Is root access still available? If
so,
is the password secure?
- Is phpMyAdmin installed on the site? That can be a weak spot.
- Do the Apache logs from the time of the breach show anything
odd/curious ?
All sage advice and good questions.
Also, at the risk of stating the obvious, I'd strongly recommend creating
a
superuser role and retiring your UID1 account for everything but upgrades/updates.
I think it's not so obvious and not really useful. If the "superuser role" has the permission to "administer users" or "administer permissions" then any user in that role has the exact same permissions as UID1. The only difference is, as you state running update.php (in D7 that distinction is gone - anyone with the right permission can run update.php).
The idea that "uid1 = unsafe" is a security myth that needs to die. There are other more likely avenues of attack such as incorrectly configured input formats.
For those interested, you can test your input formats against security best practices by trying out http://drupal.org/project/security_review
Cheers, Greg -- [ Drupal support list | http://lists.drupal.org/ ]
thanks for the heads up mate. thats a great module.
On Fri, Dec 17, 2010 at 4:47 PM, Ryan LeTulle bayousoft@gmail.com wrote:
For those interested, you can test your input formats against security
best practices by trying out http://drupal.org/project/security_review
nice, thanks
:ryan
bayousoft.com http://www.bayousoft.com twitter.com/bayousoft http://www.twitter.com/bayousoft
On Fri, Dec 17, 2010 at 10:10 AM, Greg Knaddison < Greg@growingventuresolutions.com> wrote:
On Fri, Dec 17, 2010 at 12:20 AM, Bill Fitzgerald bill@funnymonkey.com wrote:
- What roles have "administer comments" rights?
- Are there any VBO-based comments administration views on the site?
- How secure is the site's database? Is root access still available? If
so,
is the password secure?
- Is phpMyAdmin installed on the site? That can be a weak spot.
- Do the Apache logs from the time of the breach show anything
odd/curious ?
All sage advice and good questions.
Also, at the risk of stating the obvious, I'd strongly recommend
creating a
superuser role and retiring your UID1 account for everything but upgrades/updates.
I think it's not so obvious and not really useful. If the "superuser role" has the permission to "administer users" or "administer permissions" then any user in that role has the exact same permissions as UID1. The only difference is, as you state running update.php (in D7 that distinction is gone - anyone with the right permission can run update.php).
The idea that "uid1 = unsafe" is a security myth that needs to die. There are other more likely avenues of attack such as incorrectly configured input formats.
For those interested, you can test your input formats against security best practices by trying out http://drupal.org/project/security_review
Cheers, Greg -- [ Drupal support list | http://lists.drupal.org/ ]
-- [ Drupal support list | http://lists.drupal.org/ ]
The idea that "uid1 = unsafe" is a security myth that needs to die. There are other more likely avenues of attack such as incorrectly configured input formats.
There are plenty of contrib modules that check for uid == 1 and dole out additional privileges, so while Drupal core may only check for uid == 1 in user_access() and user_register_submit(), your site is only as secure as your weakest contrib module.
Here are three examples of (uid == 1) checks from a site I'm looking at now (and I'm sure you can find a module or two that I've contributed where I've done the same thing):
From workflow.module:
function workflow_field_choices($node) {
... if ($user->uid == 1) { // Superuser is special. $roles = 'ALL'; } ... }
From flag module's flag.inc:
function user_access($account = NULL) { if (!isset($account)) { $account = $GLOBALS['user']; } $matched_roles = array_intersect($this->roles, array_keys($account->roles)); return !empty($matched_roles) || empty($this->roles) || $account->uid == 1; }
From drupad.module:
function drupad_authorize() { global $user; if (!strstr($_SERVER['HTTP_USER_AGENT'], 'Drupad')) { return FALSE; } if ($user->uid == 0) { return FALSE; } if (user_access('use Drupad application')) { return TRUE; } if ($user->uid == 1) { return TRUE; } if (arg(0) == 'drupad') { drupad_unauthorized(); } return FALSE; }
- Marc
On Fri, Dec 17, 2010 at 10:19 AM, Marc Poris marc@funnymonkey.com wrote:
The idea that "uid1 = unsafe" is a security myth that needs to die. There are other more likely avenues of attack such as incorrectly configured input formats.
There are plenty of contrib modules that check for uid == 1 and dole out additional privileges, so while Drupal core may only check for uid == 1 in user_access() and user_register_submit(), your site is only as secure as your weakest contrib module.
Sure, and I've even used that fact to set the 'access arguments' on a menu item to be <? array("something that doesn't exist"), ?> so that only UID 1 can access that callback, however:
1. In a quick review it seems all the examples you showed could also be accessed with the right roles/permissions and my argument was that someone with "administer users" and "administer permissions" can already grant whatever things they need to get access to that feature.
2. Someone with those permissions can easily escalate themselves to become uid1 by enabling some module that executes PHP and then creating a snippet like <?php global $user; $user = user_load(1); ?>
Aside from Bill's followup about splitting administration roles (totally agree there, great point) but my claim is:
From a security perspective, there is no difference between UID 1 and
someone who has a role "administer users" and/or "administer permissions."
Cheers, Greg
On 12/17/10 8:10 AM, Greg Knaddison wrote:
I think it's not so obvious and not really useful. If the "superuser role" has the permission to "administer users" or "administer permissions" then any user in that role has the exact same permissions as UID1. The only difference is, as you state running update.php (in D7 that distinction is gone - anyone with the right permission can run update.php).
We always try to create targeted admin roles for specific tasks, so you can split rights like administer nodes (for high-level editors) from administer views/blocks/content types (for site admins) from administer users. This way, different types of admin users can be assembled from these various roles, and matched to professional responsibilities and individual skill sets.
The idea that "uid1 = unsafe" is a security myth that needs to die.
uid1 will be as safe or as unsafe as the person using it - and by "person" I generally mean the actual human hitting the keyboard, the computer that keyboard is attached to, and the network they are on. I'd much rather incrementally decrease risk through targeted roles - although, as you say, if a user gets "administer users" rights then all bets are off.
Another use we have found for discouraging the use of uid1 is less technical and more training-related - it's a way to start the discussion with less technical users about security concerns.
There are other more likely avenues of attack such as incorrectly configured input formats.
Absolutely.
For those interested, you can test your input formats against security best practices by trying outhttp://drupal.org/project/security_review
That is a sweet module that I didn't know existed. Thanks for sharing that.
Cheers,
Bill